IEEE P1003.0 Draft 13 - September 1991 


Copyright © 1991 by the 

Institute of Electrical and Electronics Engineers, Inc. 

345 East 47th Street 
New York, NY 10017, USA 
All rights reserved as an unpublished work. 

This is an unapproved and unpublished IEEE Standards Draft, subject to change. 
The publication, distribution, or copying of this draft, as well as all derivative 
works based on this draft, is expressly prohibited except as set forth below. 

Permission is hereby granted for IEEE Standards Committee participants to 
reproduce this document for purposes of IEEE standardization activities only, and 
subject to the restrictions contained herein. 

Permission is hereby also granted for member bodies and technical committees of 
ISO and IEC to reproduce this document for purposes of developing a national 
position, subject to the restrictions contained herein. 

Permission is hereby also granted to the preceding entities to make limited copies 
of this document in an electronic form only for the stated activities. 

The following restrictions apply to reproducing or transmitting the document in 
any form: 1) all copies or portions thereof must identify the document’s IEEE 
project number and draft number, and must be accompanied by this entire notice 
in a prominent location; 2) no portion of this document may be redistributed in 
any modified or abridged form without the prior approval of the IEEE Standards 
Department. 

Other entities seeking permission to reproduce this document, or any portion 
thereof, for standardization or other activities, must contact the IEEE Standards 
Department for the appropriate license. 

Use of information contained in this unapproved draft is at your own risk. 

IEEE Standards Department 
Copyright and Permissions 
445 Hoes Lane, P.O. Box 1331 
Piscataway, NJ 08855-1331, USA 
+1 (908) 562-3800 
+1 (908) 562-1571 [FAX] 



P1003.0 Draft 13 


STANDARDS PROJECT 

Draft Guide to the 
POSIX Open Systems Environment 


Sponsor 

Technical Committee on Operating Systems 
and Application Environments 

of the 

IEEE Computer Society 


Abstract: IEEE Std 1003.0-199x presents an overview of open system concepts 
and their application. Information is provided to persons evaluating systems on 
the existence of, and interrelationships among, application software standards, 
with the objective of enabling application portability and system interoperability. 
A framework is presented that identifies key information system interfaces 
involved in application portability and system interoperability and describes the 
services offered across these interfaces. Standards or standards activities associ¬ 
ated with the services are identified where they exist, or are in progress. Gaps 
are identified where POSIX Open Systems Environment (OSE) requirements are 
not being addressed currently. Finally, the OSE profile concept is discussed with 
examples from several application domains. 

Keywords: application portability, open systems environments, profiles, POSIX 


P1003.0/D13 
September 1991 


Copyright © 1991 by the Institute of Electrical and Electronics Engineers, Inc. 

345 East 47th Street 
New York, NY 10017, USA 
All rights reserved. 



This is an unapproved IEEE Standards Draft, subject to change. Permission 
is hereby granted for IEEE Standards Committee participants to reproduce 
this document for purposes of IEEE standardization activities. Permission 
is also granted for member bodies and technical committees of ISO and IEC 
to reproduce this document for purposes of developing a national position. 

Other entities seeking permission to reproduce this document for 
standardization or other activities, or to reproduce portions of this 
document for these or other uses, must contact the IEEE Standards 
Department for the appropriate license. Use of information contained in 
this unapproved draft is at your own risk. 

IEEE Standards Department 
Copyright and Permissions 
445 Hoes Lane, P.O. Box 1331 
Piscataway, NJ 08855-1331, USA 
+1 (908) 562-3800 
+1 (908) 562-1571 [FAX] 

September 1991 SH XXXXX 


Copyright © 1991 IEEE. All rights reserved. 

This is an unapproved IEEE Standards Draft, subject to change. 



1 Editor’s Notes 

2 This section will not appear in the final document. It is used for editorial com- 

3 ments concerning this draft. 

4 Comments in italics are not intended to form part of the final guide; they are 

5 editor’s or coordinator comments for the benefit of reviewers. 

6 This draft uses small numbers in the right margin in lieu of change bars, “d” d 

7 denotes changes from Draft 12 to Draft 13. Per request of the working group, I D 

8 have removed all old diff-marks from Drafts 3 through 12. Purely editorial D 

9 changes such as grammar, spelling, cross references, or removals of editorial 

10 notes are not diff-marked. Unfortunately, it is not possible to accurately diff- 

n mark the figures. 

12 To make draft handling in the meetings easier, each significant clause is set up to 

13 print starting on a recto page. This means that there is a larger number of blank 

14 pages than in previous drafts (assuming that the copy room handled the print 

15 master correctly). Just doing our bit for deforestation ... 

16 This draft has not yet been converted to use proper normative reference and D 

17 bibliographic entries and cross references. Since this will entail a large amount of D 

is detailed work, I have been awaiting some degree of text stability. For Draft 13, d 

19 three major sections were replaced in their entirety (and, interestingly enough, all D 

20 three were received approximately one month after the input cutoff date), so I D 

21 believe the required stability has not yet been achieved. D 

22 Hal Jespersen d 
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23 Editorial Contacts 

24 Please send comments regarding the content and approach of this document to: 

25 Fritz Schulz 

26 Open Software Foundation 

27 620 Herndon Parkway - Suite 200 

28 Herndon, VA 22070 

29 +1 (703) 481-9851 

30 FAX: +1 (703) 437-0680 

31 E-Mail: fschulz@osf.ORG 

32 Please report typographical errors (and index suggestions) to: 

33 Hal Jespersen 

34 POSIX Software Group 

35 4 47 Lakeview Way 

36 Redwood City, CA 94062 

37 +1 (415) 364-3410 

38 FAX: +1 (415) 364-4498 

39 E-Mail:hlj@Posix.C0M 

40 (Electronic mail is preferred.) 
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41 Online Access d 

42 This draft is available in various electronic forms to assist the review process, d 

43 Our thanks to Andrew Hume of AT&T Bell Laboratories for providing online D 

44 access facilities. Note that this is a limited experiment in providing online access; d 

45 future drafts may be provided in other forms, such as diskettes or a bulletin board D 

46 arrangement, but the instructions shown here are the only methods currently D 

47 available. Please also observe the additional copyright restrictions that are d 

48 described in the online files. d 

49 Assuming you have access to the Internet, the scenario is approximately D 

50 ftp research.att.com # research's IP address is 192.20.225.2 D 

51 <login as netlib; password is your email address> D 

52 cd posix/pl003.0/dl3 D 

53 get toe index D 

54 binary D 

55 get pll-20.Z D 

56 The draft is available in several forms. The table of contents can be found in toe, D 

57 pages containing a particular section are stored under the section number, sets of D 

58 pages are stored in files with names of the form p n-m, and the entire draft is d 

59 stored in all. By default, files are ASCII. A . ps suffix indicates PostScript. A.Z D 

60 suffix indicates a compress’ed file. The file index contains a general description D 

61 of the files available. d 

62 These files are also available via electronic mail by sending a message like d 

63 send 3.4 4.6 6.2 from posix/pl003.0/dl3 D 

64 to netlib@research.att.com. If you use email, you should not ask for the D 

65 compressed version. For a more complete introduction to this form of netlib, send D 

66 the message d 

67 send help D 
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68 

POSIX.O Change History 


69 

This section is 

provided to track major changes between drafts. Since it was first 


70 

added in Draft 10, earlier entries have been omitted. 


71 

Draft 13 

[September 1991] 

D 

72 


— To Be Provided 

D 

73 

Draft 12 

[June 1991] 


74 


— Clause 4.9: Separated OLTP model discussion into two 

D 

75 


parts: the part consistent with the POSIX OSE Model; and 

D 

76 


the “real world” part dealing with System Integration 

D 

77 


Interfaces. 

D 

78 


— Section 6: Further clarified “base standard” and “profile” 

D 

79 


definitions. Renamed profile “types”. 

D 

80 


— Additional To Be Provided 

D 

81 

Draft 11 

[March 1991] 


82 


— To Be Provided 


83 


HLJ: I don’t do this automatically because I don’t know 


84 


what issues you consider important. This [very brief] text 


85 


should be provided by each Section Leader along with the 


86 


regular submissions. It is meant to provide casual readers 


87 


of the guide (such as in WG15, where they don’t get every 


88 


draft) with a broad overview of the big changes. 


89 

Draft 10 

[December 1990] 


90 


— To Be Provided 
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IEEE Standards documents are developed within the Technical Committees of 
the IEEE Societies and the Standards Coordinating Committees of the IEEE Stan¬ 
dards Board. Members of the committees serve voluntarily and without compen¬ 
sation. They are not necessarily members of the Institute. The standards 
developed within IEEE represent a consensus of the broad expertise on the subject 
within the Institute as well as those activities outside of IEEE that have expressed 
an interest in participating in the development of the standard. 

Use of an IEEE Standard is wholly voluntary. The existence of an IEEE Standard 
does not imply that there are no other ways to produce, test, measure, purchase, 
market, or provide other goods and services related to the scope of the IEEE Stan¬ 
dard. Furthermore, the viewpoint expressed at the time a standard is approved 
and issued is subject to change brought about through developments in the state 
of the art and comments received from users of the standard. Every IEEE Stan¬ 
dard is subjected to review at least every five years for revision or reaffirmation. 
When a document is more than five years old and has not been reaffirmed, it is 
reasonable to conclude that its contents, although still of some value, do not 
wholly reflect the present state of the art. Users are cautioned to check to deter¬ 
mine that they have the latest edition of any IEEE Standard. 

Comments for revision of IEEE Standards are welcome from any interested party, 
regardless of membership affiliation with IEEE. Suggestions for changes in docu¬ 
ments should be in the form of a proposed change of text, together with appropri¬ 
ate supporting comments. 

Interpretations: Occasionally questions may arise regarding the meaning of por¬ 
tions of standards as they relate to specific applications. When the need for 
interpretations is brought to the attention of the IEEE, the Institute will initiate 
action to prepare appropriate responses. Since IEEE Standards represent a con¬ 
sensus of all concerned interests, it is important to ensure that any interpretation 
has also received the concurrence of a balance of interests. For this reason, the 
IEEE and the members of its technical committees are not able to provide an 
instant response to interpretation requests except in those cases where the matter 
has previously received formal consideration. 

Comments on standards and requests for interpretations should be addressed to: 

Secretary, IEEE Standards Board 

445 Hoes Lane 

P.O. Box 1331 

Piscataway, NJ 08855-1331 


IEEE Standards documents are adopted by the Institute of Electrical and Elec¬ 
tronics Engineers without regard to whether their adoption may involve 
patents on articles, materials, or processes. Such adoption does not assume 
any liability to any patent owner, nor does it assume any obligation whatever to 
parties adopting the standards documents. 
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Introduction 


(This Introduction is not a normative part of P1003.0 Guide to the POSIX Open Systems Environ¬ 
ment, but is included for information only.) 


1 Purpose 

2 There are many standards efforts going on throughout the world today. Stan- 

3 dards are being developed in many areas of computing technology such as: 

4 — Electrical Connectors 

5 — Disk Interfaces 

6 — Network Interfaces 

7 — Application Program Interfaces 

8 Each standards effort typically addresses a very small portion of the overall needs 

9 of an information processing system. 

10 This guide is an attempt bring together many different standards sufficient to 

n address the scope of an entire information processing system. This combination 

12 of standards and specifications that are sufficient to address all of the user 

13 requirements of an information processing system is called an Open System 

14 Environment. 

15 User requirements and standards to meet those requirements are continuously 

16 expanding. As such, this guide will need regular revision to incorporate new user 

17 requirements and the new standards that evolve to meet those user requirements. 

18 This guide is not a standard itself; it merely identifies standards that can be used 

19 when constructing a complete information processing system. 

20 It may never be necessary to implement an information processing system that 

21 provides every standard in the POSIX Open System Environment. Typically a 

22 subset of the standards is sufficient to satisfy the particular user requirements in 

23 each situation. 

24 This process of selecting standards for a particular application is called profiling. 

25 Recommendations for the production of different types of profiles are included in 

26 the guide. 

27 This guide is intended to be used by any computer user interested in using stan- 

28 dards in their information processing systems including: consumers, systems 

29 integrators, application developers, systems providers, and procurement agencies. 

30 Taken as a whole, the guide maps existing and emerging standards onto the gen- 

31 eral requirements of a complete information processing system. In addition to 

32 listing and categorizing existing standards efforts, the guide identifies important 

33 requirements that standards efforts have not yet addressed. 
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34 The POSIX Open System Environment Reference Model 


35 To describe the POSIX Open System Environment, the guide develops a reference 

36 model used to classify information processing standards. The reference model 

37 breaks standards into three general categories: 

38 — Platform External Interface Standards—These standards affect how an 

39 information processing system interacts with its external environment. 

40 These standards affect system interoperability, user interface look and feel, 

41 and data portability. 

42 — Application Program Interface Standards—These standards affect how 

43 application software interacts with the computer system. These standards 

44 affect application portability. 

45 — System Integration Interface Standards—These interfaces have no direct 

46 impact on the external interface of a system or the application program 

47 interface to the system. These interfaces are between the various parts of 

48 an information processing system. These standards are very important 

49 because they allow a user to independently procure portions of their infor- 

50 mation processing systems from multiple vendors according to each user’s 

51 needs. 

52 The information processing system is broken into major component areas. Using 

53 the reference model, a general set of requirements for each component area is 

54 developed. For each of the requirements existing or emerging standards are 

55 identified that address the requirement. If a requirement is not completely met 

56 by an existing or emerging standard, this gap in the standards is noted. 

57 Goals 

58 There are three goals of the POSIX OSE: portability, interoperability, and user 

59 portability. (While these terms are formally defined later in this guide and within 

60 various referenced standards, the following descriptions provide an overview of 

61 their meaning.) 

62 Portability 

63 Portability is accomplished through the use of the respective 

64 system/application interface standards and their extensions, thus allow- 

65 ing a user’s application to operate on a wide range of systems. It is 

66 important to note that the aforementioned phrase “wide range of sys- 

67 terns” connotes diverse hardware as well as software platforms. 

68 Using standards to provide application portability also will allow an 

69 application to be moved to systems with varying compute capabilities 

70 based on the performance needs of the application. 

71 Interoperability 

72 Interoperability is characterized by the cooperative operation of applica- 

73 tions resident on dissimilar computer systems. This cooperative opera- 

74 tion is illustrated by data and functionality exchange. 
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75 User Portability 

76 User portability will allow users to move from system to system and 

77 between different applications on the same system with a minimum of 

78 retraining. 

79 Benefits 


80 The benefits derived in the use of the POSIX Open System Environment are real 

81 and quantifiable. 


82 Simplified Vendor Mixing System Integration 

83 As the standards for system integration and system interoperability are 

84 produced and implemented, the users will have the choice of mixing 

85 software and equipment from multiple vendors. This will allow users to 

86 tailor their information processing system to their particular needs by 

87 selecting their hardware based on the application needs rather than its 

88 ability to interoperate with their existing equipment. 

89 Efficient Development and Implementation 

90 Normally, systems users and providers have development and imple- 

91 mentation activities that utilize personnel possessing skills in a specific 

92 computer environment. As a result of this specialization, a change in 

93 the target computer environment for a developer requires significant 

94 retraining expense. As standards for application portability, system 

95 interoperability, and system integration are developed, computer per- 

96 sonnel will begin to develop skills in working with these standards. 

97 When these standards are widely used there will be large pool of person- 

98 nel who are familiar with working with the standards. 

99 This will allow a company to hire personnel with existing skills which 

100 can be put to use in their operation. In addition, within a company, 

101 resources can be redeployed between development efforts with a 

102 minimum of retraining. 


103 As the basic interfaces are developed and well defined, higher level 

104 standardized interfaces can be developed that add value to the basic 

105 interfaces. Using the higher level interfaces may speed development 

106 efforts. 


107 Efficient Porting of Applications 

108 The difficulty of moving an application from one hardware/software 

109 environment to another is widely known. The porting of an application 

no that uses standards-based interfaces to another system that provides 

in the same standards-based interfaces is considerably simpler than ports 

112 involving completely different systems. The amount of system tailoring 

113 (i.e., changes to either the operating or application system required to 

H4 make them work well together) is greatly reduced. 

115 Broadened Basis for Computer System Procurement Decisions 
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116 Computer users can now select and match hardware and software com- 

117 ponents from potentially different suppliers to fulfill an application 

ns requirement. This in turn allows decisions regarding computer systems 

119 procurements to be based less upon constraints imposed by incumbent 

120 vendors’ products. The basis for competition will refocus on such factors 

121 as price, quality, value-added features, performance, and support. The 

122 stimulation of competition will benefit providers and users. 

123 Reduced Personnel Training 

124 Both providers and users of computer systems face high training costs 

125 when they switch hardware/software environments within which their 

126 application exists. Usage of standards makes inroads into reducing the 

127 costs of retraining users of all types. Reduced training will be incurred 

128 for developers and end-users alike. 

129 Related Standards Activities 

130 The Standards Subcommittee of the IEEE Technical Committee on Operating Sys- 

131 terns and Application Environments has authorized other standards activities 

132 that are related to the content of this guide. 

133 The following areas are under active consideration at this time, or are expected to 

134 become active in the near future: 1 * 

135 (1) Language-independent service descriptions of the POSIX.1 {2} system 

136 application program interface (API) 

137 (2) C, Ada, and FORTRAN Language bindings to (1) 

138 (3) Shell and Utility facilities 

139 (4) Verification testing methods 

140 (5) Realtime facilities 

141 (6) Secure/Trusted System considerations 

142 (7) Network interface facilities 

143 (8) System Administration 

144 (9) Graphical User Interfaces 

145 (10) Profiles describing application- or user-specific combinations of Open Sys- 

146 terns standards for: supercomputing, multiprocessor, and batch exten- 

147 sions; transaction processing; realtime systems; and multiuser systems 

148 based on historical models 

149 1) A Standards Status Report that lists all current IEEE Computer Society standards projects is 

150 available from the IEEE Computer Society, 1730 Massachusetts Avenue NW, Washington, DC 

151 20036-1903; Telephone: +1 202 371-0101; FAX: +1 202 728-9614. Working drafts of POSIX 

152 standards under development are also available from this office. 
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153 Extensions are approved as “amendments” or “revisions” to this document, follow- 

154 ing the IEEE and ISO/IEC Procedures. 

155 Approved amendments are published separately until the full document is 

156 reprinted and such amendments are incorporated in their proper positions. 

157 If you have interest in participating in the TCOS working groups addressing these 

158 issues, please send your name, address, and phone number to the Secretary, IEEE 

159 Standards Board, Institute of Electrical and Electronics Engineers, Inc., P.O. Box 

160 1331, 445 Hoes Lane, Piscataway, NJ 08855-1331, and ask to have this forwarded 

161 to the chairperson of the appropriate TCOS working group. If you have interest in 

162 participating in this work at the international level, contact your ISO/IEC national 

163 body. 

164 P1003.0 was prepared by the 1003.0 working group, sponsored by the Technical 

165 Committee on Operating Systems and Application Environments of the IEEE 

166 Computer Society. At the time this standard was approved, the membership of 

167 the 1003.0 working group was as follows: 

168 Technical Committee on Operating Systems 

169 and Application Environments (TCOS) 

170 Chair: Jehan-Franqois Paris 

171 TCOS Standards Subcommittee 
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When the IEEE Standards Board approved this standard on <date to be pro- 
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P1003.0/D13 


Guide to the POSIX Open Systems Environ¬ 
ment 


Section 1: General 


Responsibility: Kevin Lewis 


1.1 Scope 

This guide identifies parameters for an open system environment using the POSIX 
operating system/application interface as the platform. These parameters are 
determined in three basic ways: 

(1) By specifying building blocks identified as components 

Currently these components are: system services, networking, 
human/computer interaction (HCI), graphics, system security and 
privacy, database, data interchange, and language requirements. This 
guide identifies the standards required within each component to achieve 
the goals of a POSIX open system. 

(2) By identifying intra- and intercomponent issues 

These issues involve the relationships that should exist between and 
among the different components. It is in the attempt to lay out and 
address these relationships that the concept of profiles (see 2.2.2 and Sec¬ 
tion 6) arises. 

(3) By identifying voids 
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GUIDE TO THE POSIX OPEN SYSTEMS 


is A void is determined by the absence, or lack of maturity, of formal stan- 

19 dards development efforts. Voids may exist within available standards 

20 or may be an entire component. This guide provides assistance to those 

21 users who have already constructed, or plan to construct, profiles and to 

22 those users who currently use, or plan to use, profiles. The profile con- 

23 cept allows users to identify those standards that address their specific 

24 needs. The profile also serves to identify the need for future standards 

25 development in a specific area. This guide explains the manner in which 

26 these standards relate to each other. 


27 1.2 Normative References 


28 HLJ: A list of referenced standards and other publications needs to be provided, 

29 contrasted against the list of interesting background documents that should go into 

30 the bibliography, included as Appendix C. I have included some dummy references 

31 here, so you can see the style; these standards need not be appropriate normative 

32 references. 

33 The following standards contain provisions which, through references in this text, 

34 constitute provisions of this guide. At the time of publication, the editions indi- 

35 cated were valid. All standards are subject to revision, and parties to agreements 

36 based on this part of this International Standard are encouraged to investigate 

37 the possibility of applying the most recent editions of the standards listed below. 

38 Members of IEC and ISO maintain registers of currently valid International Stan- 

39 dards. 


40 {1} ISO 8859-1: 1987, Information processing — 8-bit single-byte coded graphic 

41 character sets—Part 1: Latin alphabet No. 1. 1} 


42 {2} ISO/IEC 9945-1: 1990, Information technology—Portable operating system 

43 interface (POSIX)—Part 1: System application programming interface (API) 

44 1C Language] 


45 1) ISO documents can be obtained from the ISO office, 1, rue de Varembe, Case Postale 56, CH-1211, 

46 Geneve 20, Switzerland/Suisse. 
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47 

1.3 Conformance 


48 

Not applicable. 

D 
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Section 2: Terminology and General Requirements 


i Responsibility: John Williams 


2 2.1 Conventions 

3 This guide uses the following typographic conventions: 

4 — The italic font is used for cross references to defined terms within 1.3, 2.2.1, 

5 and 2.2.2. 

D 

6 In some cases tabular information is presented “inline;” in others it is presented 

7 in a separately labeled Table. This arrangement was employed purely for ease of 

8 typesetting and there is no normative difference between these two cases. 

9 The typographic conventions listed above are for ease of reading only. Editorial 

10 inconsistencies in the use of typography are unintentional and have no normative 

n meaning in this guide. 

12 NOTEs provided as parts of labeled Tables and Figures are integral parts of this 

13 guide (normative). Footnotes and NOTEs within the body of the text are for infor- 

14 mation only (nonnormative). 


is 2.2 Definitions 

16 2.2.1 Terminology 

17 For the purposes of this guide, the following definitions apply: 

18 2.2.1.1 implementation defined: An indication that the implementation shall 

19 define and document the requirements for correct program constructs and correct 

20 data of a value or behavior. 

21 2.2.1.2 informative: Providing or disclosing information; instructive. D 

22 Used in standards to indicate a portion of the text that poses no requirements; the D 

23 opposite of normative . D 
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24 2.2.1.3 may: An indication of an optional feature. 

25 With respect to implementations, the word may is to be interpreted as an optional 

26 feature that is not required in this guide, but can be provided. 

27 2.2.1.4 normative: Of, pertaining to, or prescribing a norm or standard. D 

28 Used in standards to indicate a portion of the text that poses requirements. D 

29 2.2.1.5 should: With respect to implementations, an indication of an implemen- 

30 tation recommendation, but not a requirement. 

31 2.2.1.6 POSIX: The term “POSIX” has been evolving recently into a generally 

32 positive term with, unfortunately, a number of different meanings. This sub- 

33 clause attempts to define the word and some related terms. The intent is to 

34 insure that the term POSIX is used in a useful and predictable manner in this 

35 document. 

36 As background, note that POSIX is sometimes used to denote the formal standard 

37 IEEE Standard 1003.1-1990, sometimes to denote that standard plus related stan- 

38 dards and drafts emerging from IEEE P1003.X working groups, and sometimes to 

39 denote the groups themselves. In all those cases, it should be noted, POSIX is 

40 used as a noun. 

41 This document will use the term “POSIX” only as an adjective, and will use it only 

42 in well defined ways. This subclause serves as a preview of the usages in this 

43 book of POSIX terms. (These terms are defined, formally, or informally in subse- 

44 quent clauses, and you will be referred to those clauses as appropriate.) 

45 The original POSIX standard will be referred to by its name, ISO 9945, and not by 

46 the term POSIX. 

47 The IEEE groups developing standards related to ISO 9945 are called, in this 

48 document, POSIX working groups. Examples are the IEEE working groups 

49 P1003.2, P1003.3, etc. The groups’ names will be abbreviated POSIX.2, POSIX.3, 

50 etc. 

51 The standards emerging out of the POSIX working groups will be referred to by 

52 their formal names (e.g., IEEE P1003.2 Draft 9) and are called either POSIX Base 

53 Standards or POSIX Standardized Profiles (POSIX SPs). 

54 2.2.2 General Terms 

55 For the purposes of this guide, the following definitions apply: 

56 2.2.2.1 application: The use of capabilities (services/facilities) provided by an 

57 information system specific to the satisfaction of a set of user requirements. 

58 NOTE: These capabilities include hardware, software, and data. 
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59 2.2.2.2 application platform: A set of resources that support the services on 

60 which an application or application software will run. 

61 The application platform provides services at its interfaces that, as much as possi- 

62 ble, make the specific characteristics of the platform transparent to the 

63 application. 

64 2.2.2.3 application program interface (API): The interface between the 

65 applications software and the applications platform, across which all services are 

66 provided. 

67 The application program interface is primarily in support of application portabil- 

68 ity, but system and application interoperability are also supported via the com- 

69 munications API. 

70 2.2.2.4 application software: Software that is specific to an application and is 

71 composed of programs, data, and documentation. 

72 2.2.2.5 Applications Environment Profile (AEP): A profile, specifying a com- D 

73 plete and coherent subset of an OSE, in which standards, options, and parameters D 

74 chosen are necessary to support a class of applications. d 

75 AEPs are intended for use in procurement, conformance testing, and designating a 

76 software engineering target. 

77 2.2.2.6 base standard: A standard or specification that is recognized as 

78 appropriate for normative reference in a profile by the body adopting that profile. 

79 2.2.2.7 Communications Interface: The boundary between application 

80 software and the external environment, such as other application software, exter- 

81 nal data transport facilities, and devices. 

82 The services provided are those whose protocol state, syntax, and format all must 

83 be standardized for interoperability. 

84 2.2.2.8 domain: A field of influence, such as office or industrial automation, 

85 transaction processing, or realtime control systems. 

86 2.2.2.9 External Environment Interface (EEI): The interface between the 

87 application platform and the external environment across which information is 

88 exchanged. 

89 The External Environment Interface is defined primarily in support of system and 

90 application interoperability. 

91 The primary services present at the External Environment Interface comprise: 

92 — Human/Computer Interaction Services 
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93 — Information Services 

94 — Communications Services 

95 2.2.2.10 external environment: A set of external entities to the application 

96 platform in which information is exchanged. 

97 These devices include displays, disk drives, sensors, and effectors directly accessi- 

98 ble within the system. 

99 2.2.2.11 hardware: Physical equipment used in data processing as opposed to 

100 programs, procedures, rules, and associated documentation. 

101 2.2.2.12 Human/Computer Interface: The boundary across which physical 

102 interaction between a human being and the application platform takes place. 

103 2.2.2.13 Information Interchange Interface: The boundary across which 

104 external, persistent storage service is provided. 

105 Only the format is required to be specified for data portability and interoperabil- 

106 ity. 

107 2.2.2.14 interface: The shared boundary between two functional units, defined 

108 by functional characteristics and other characteristics, as appropriate. 

109 2.2.2.15 internationalization: The process of designing and developing a pro- 
no duct with a set of features, functions, and options intended to facilitate the adap- 

111 tation of the product to satisfy a variety of cultural environments. 

112 2.2.2.16 interoperability: The ability of two or more systems to exchange infor- 

113 mation and to mutually use the information that has been exchanged. 

114 2.2.2.17 language-binding API: The interface between applications and appli- D 

115 cation platforms based on language-independent binding APIs and consistent with D 

116 the paradigms used for a specific programming language. D 

117 2.2.2.18 language-independent service specification: A specification that D 

118 facilitates the management and development of consistent language-binding stan- D 

H9 dards. d 

120 2.2.2.19 locale: A description of a cultural environment. 

121 2.2.2.20 localization: The process of utilizing the internationalization features 

122 to create a version of the product for a specific culture. 
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123 2.2.2.21 local adaptation: The process of modifying a product that has hard- 

124 coded biases of one culture to the hard-coded biases of another culture. 

125 2.2.2.22 open specifications: Public specifications that are maintained by an 

126 open, public consensus process to accommodate new technologies over time and 

127 that are consistent with international standards. 

128 2.2.2.23 Open System Application Program Interface: A combination of 

129 standards-based interfaces specifying a complete interface between an application 

130 program and the underlying application platform. 

131 This is divided into the following parts: 

132 — Human/Computer Interaction Services API 

133 — Information Services API 

134 — Communications Services API 

135 — System Services API 

136 2.2.2.24 open system: A system that implements sufficient open specifications 

137 for interfaces, services, and supporting formats to enable properly engineered 

138 applications software: 

139 — to be ported with minimal changes across a wide range of systems 

140 — to interoperate with other applications on local and remote systems 

141 — to interact with users in a style that facilitates user portability. 

142 2.2.2.25 Open System Environment (OSE): The comprehensive set of inter- D 

143 faces, services, and supporting formats, plus user aspects for interoperability or D 

144 for portability of applications, data, or people, as specified by information technol- D 

145 ogy standards and profiles. D 

146 2.2.2.26 performance: A measure of a computer system or subsystem to per- 

147 form its functions; for example, response time, throughput, number of transac- 

148 tions per second. 

149 2.2.2.27 performance evaluation: The technical assessment of a system or 

150 system component to determine how effectively operating objectives have been 

151 achieved. 

152 2.2.2.28 performance requirement: A requirement that specifies a perfor- 

153 mance characteristic that a system or system component must possess; for exam- 

154 pie, speed, accuracy, frequency. 
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155 2.2.2.29 portability: The ease with which software can be transferred from one 

156 information system to another. 

157 2.2.2.30 POSIX Open System Environment (POSIX OSE): The Open System D 

158 Environment in which the standards included are International, Regional, and D 

159 National Information Technology Standards and profiles that are in accord with D 

160 ISO/IEC 9945 (POSIX). D 

161 This guide represents the POSIX OSE as it existed when the guide was approved. 

162 2.2.2.31 POSIX OSE Cross-Category Services: A set of tools and/or features 

163 that has a direct effect on the operation of one or more component of the POSIX 

164 Open System Environment, but is not in and of itself a stand-alone component. 

165 2.2.2.32 POSIX Standardized Profile (POSIX SP): A Standardized Profile that 

166 specifies the application of certain POSIX base standards in support of a class of 

167 applications and does not require any departure from the structure defined by the 

168 POSIX.O Reference Model for POSIX systems. 

169 NOTE: Which POSIX base standards form the basis of the POSIX SPs is still open. Annex A 

170 discusses some of the issues involved. 

171 2.2.2.33 process: An address space and single thread of control that executes d 

172 within that address space, and its required system resources. 

173 A process is created by another process issuing the fork() function. The process 

174 that issues fork{) is known as the parent process, and the new process created by 

175 the fork () as the child process. 

176 2.2.2.34 profile: A set of one or more base standards, and, where applicable, the 

177 identification of chosen classes, subsets, options, and parameters of those base 

178 standards, necessary for accomplishing a particular function. D 

179 2.2.2.35 programming language API: The interface between applications and D 

iso application platforms traditionally associated with programming language D 

181 specifications, such as program control, math functions, string manipulation, etc. D 

182 2.2.2.36 protocol (OSI): A set of semantic and syntactic rules that determine 

183 the behavior of [OSI-] entities in the same layer in performing communication 

184 functions. 

185 2.2.2.37 redirection: A system profile construction method of starting at a base 

186 platform and adding new services by allowing a service component to ask the base 

187 platform to redirect all requests for that type of service to the service component. 


Copyright © 1991 IEEE. All rights reserved. 

This is an unapproved IEEE Standards Draft, subject to change. 


10 


2 Terminology and General Requirements 



ENVIRONMENT INTERIM DOCUMENT 


P1003.0/D13 


188 2.2.2.38 public specifications: Specifications that are available to anyone for d 

189 implementation and distribution (i.e., sale) of that implementation without res- D 

190 triction. D 

191 2.2.2.39 reference model: A simplified description or representation of some- 

192 thing. 

193 2.2.2.40 scaleability: The ease with which software can be transferred from one D 

194 graduated series of application platforms to another. d 

195 A simplified description or representation of something. 

196 2.2.2.41 security: The protection of computer hardware and software from 

197 accidental or malicious access, use, modification, destruction, or disclosure. 

198 Tools for the maintenance of security are focused on availability, confidentiality, 

199 and integrity. 

200 2.2.2.42 service delivery latency: The interval between (a) context switch 

201 from an application context to the operating system context, and (b) satisfaction of 

202 the service request. 

203 2.2.2.43 service request latency: The interval between (a) context switch from 

204 an application context to the operating system context, and (b) the reverse context 

205 switch from the operating system context to the application context for a given 

206 service request. 

207 2.2.2.44 software: The programs, procedures, rules, and any associated docu- 

208 mentation pertaining to the operation of a data processing system. 

209 2.2.2.45 specification: A document that prescribes, in a complete, precise, D 

210 verifiable manner, the requirements, design, behavior, or characteristics of a sys- D 

211 tern or system component. D 

212 2.2.2.46 standardized profile: A balloted, formal, harmonized document that D 

213 specifies a profile. d 

214 2.2.2.47 standards: Documents, established by consensus and approved by a D 

215 recognized body, that provide, for common and repeated use, rules, guidelines, or 

216 characteristics for activities or their results, aimed at the achievement of the 

217 optimum degree of order in a given context. 

218 NOTE: Standards should be based on the consolidated results of science, technology, and experi- 

219 ence, and aimed at the promotion of optimum community benefits. 
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220 2 . 2 . 2.48 System Internal Interface (SII): The interface between application d 

221 platform service components within that platform; it may be standardized or non- D 

222 standard. D 

223 2.2.2.49 system services: Firmware and software that provide an aggregation 

224 of network element functions into a higher level function; provide an interface to 

225 the data contained in the system. 

226 2.2.2.50 System Services API: An interface providing access to services associ- 

227 ated with the application’s internal resources. 

228 The System Services API has two parts: Language Specifications and Processing 

229 Services API. 

230 2 . 2 . 2.51 system software: Application-independent software that supports the 

231 running of application software. 

232 2 . 2 . 2.52 transaction: A unit of work consisting of an arbitrary number of indivi- 

233 dual operations all of which will complete successfully (or be of no effect) on the 

234 intended resources. 

235 A transaction has well defined boundaries. A transaction starts with a request 

236 from the application program and either completes successfully (commits) or has 

237 no effect (abort). Both the commit and abort signify a transaction completion. 

238 2 . 2 . 2.53 transaction application program: A program written to meet the D 

239 requirements of a chosen Transaction Processing (TP) application. 

240 Such programs allow a sequence of operations that involve resources such as ter- 

241 minals and databases. The transaction AP specifies transaction boundaries. The 

242 transaction AP as defined here is a logical entity and may involve an arbitrary 

243 number of processes. 

244 2 . 2 . 2.54 validation: The process of evaluating a ported application, software, or 

245 system to ensure compliance with requirements. 

246 2.2.3 Abbreviations 

247 For the purposes of this guide, the following abbreviations apply: 

248 2 . 2 . 3.1 API: Application Program Interface 

249 2 . 2 . 3.2 EEI: External Environment Interface 
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250 2.2.3.3 POSIX.O: This guide. 

251 2.2.3.4 POSIX.n: An IEEE POSIX working group, where the number n represents 

252 the decimal notation in the IEEE P 1003 series. Alternatively, when apparent 

253 from context, the latest standard issued, or under development, by that working 

254 group. 

255 2.2.3.5 SII: System Internal Interface. d 
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Section 3: POSIX Open System Environment 


1 Responsibility: Fritz Schulz 

2 The POSIX Open System Environment (OSE) is a collection of concepts that pro- 

3 vide a context for user requirements and standards specification. It provides a 

4 minimum, standard set of conceptual information system building blocks with 

5 associated interfaces and functionality. The POSIX OSE consists of a reference 

6 model, service definitions, standards, and profiles. 

7 These OSE concepts are also intended to be conventional within computer science. 

8 The intention is not to break new ground, but to establish a minimum and unam- 

9 biguous terminology and set of concepts for identification and resolution of porta- 

10 bility and interoperability issues. 

n The POSIX Open System Environment is defined in five parts: 

12 ( 1 ) General requirements are identified that apply to the POSIX OSE as a 

13 whole in 3 . 1 . 


14 

15 

16 

17 

18 
19 


( 2 ) A reference model is developed that unambiguously identifies the system 
under consideration for purposes of specification. The POSIX OSE refer¬ 
ence model described in 3.2 defines system elements to identify interfaces 
across which service requirements should be satisfied. The elements are 
chosen to expose those interfaces that are significant to the profile writer 
or user. 


20 

21 

22 

23 

24 


( 3 ) Using the interfaces identified in the reference models, each subclause of 
Section 4 categorizes and describes the basic services available to users 
across each interface. The services are defined in a generic way, based on 
the reference model, user requirements, and current industry practice, 
rather than any given implementation. 


25 

26 

27 

28 


Definition of the service requirements is not constrained by the availabil¬ 
ity of standards. Service requirements that are not currently satisfied 
via standards are discussed in either the Emerging Standards subclause, 
or under Gaps. 


29 

30 

31 

32 


Each clause of Section 4 begins with a more detailed and specialized ver¬ 
sion of the reference model to provide a context for service specification. 
After defining the interfaces and services, each of the Section 4 clauses 
concludes with a discussion of standards that are related to the services. 


33 ( 4 ) Section 5 discusses issues and requirements that directly affect all of the 

34 service categories, such as internationalization, security, and 
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35 administration. 

36 (5) Section 6 provides guidelines for creating profiles that address various 

37 application domains. This is a brief description of how the reference 

38 model and services are applied to a variety of existing types of systems. 

39 Section 7 describes current POSIX profiles and profiling activities. 

40 The text emphasizes the concept of service requirements (rather than services) to 

41 emphasize that the POSIX OSE only includes requirements, not solutions which 

42 satisfy those requirements. It is the standards and profiles listed in the sub- 

43 clauses of Sections 4 and 5 that will satisfy these requirements. 

44 Definition of the service requirements is not constrained by the availability of 

45 standards. Services requirements that are not currently satisfied via standards 

46 are discussed in either the Emerging Standards subclause, or under Gaps. 


47 3.1 POSIX Open System Environment — General Requirements 

48 The POSIX Open System Environment should satisfy the requirements in the fol- 

49 lowing list: 

so (1) Application Portability at the Source Code Level 

51 The POSIX OSE shall enable application software portability at the source 

52 code level. 

53 Rationale: Comprehensive and consistent source code level service 

54 specifications allow porting of applications among processors (ideally 

55 without modification). Binary portability requires too tight a coupling 

56 with the processor implementation. 

57 (2) System Interoperability 

58 The POSIX OSE shall enable application software and system service 

59 interoperability. 

60 Rationale: Communications services and format specifications allow two d 

61 entities participating in a distributed system to exchange and make 

62 mutual use of data, including: 

63 — Homogeneous systems 

64 — Heterogeneous systems (i.e., a wide variety of hardware/software plat- 

65 forms) 

66 — POSIX-OSE-based and non-OSE-based systems 

67 (3) User Portability 

68 The POSIX OSE shall enable human users to operate on a wide range of 

69 systems without retraining. 

70 Rationale: Standard methods and services for supporting 

71 human/computer interaction are a key aspect of the definition of an open 
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72 

73 

74 

75 

76 

77 

78 

79 

80 
81 
82 

83 

84 

85 

86 

87 

88 

89 

90 

91 

92 

93 

94 

95 

96 

97 

98 

99 

100 
101 
102 

103 

104 

105 

106 

107 

108 

109 

110 
111 
112 


system (see Section 2). Elimination of gratuitous differences in the inter¬ 
face that the application platform presents to the user via standards is a 
significant aspect of this task. 

(4) Accommodation of Standards 

The POSIX OSE shall accommodate existing, imminent, and new informa¬ 
tion technology standards. 

Rationale: If the POSIX OSE were constrained to current technology, it 
would quickly become obsolete. It would also not be capable of providing 
a complete set of applicable standards and profiles, as efforts to-date 
have not yet provided a full suite of applicable standards. The POSIX 
OSE must evolve as standards emerge and technology changes. 

An inevitable tension exists between establishing fixed standards and 
providing for technology enhancement. Therefore, the POSIX OSE must 
be sufficiently general to allow for technology growth and yet specific 
enough to act as a guide for standards development. 

(5) Accommodation of New Information System Technology 

The POSIX OSE shall accommodate new Information System Technology. 

Rationale: The POSIX OSE must strive to satisfy the full range of the 
users’ functional requirements. This is undoubtedly a requirement that 
will only be fully realized over time, but it reflects the goal of the POSIX 
OSE. 

(6) Application Platform Scalability 

The POSIX OSE shall be scalable to platforms of varying power and imple¬ 
mentation complexity. 

Rationale: This reflects the realities of the potential users of the POSIX 
OSE. This requirement affects individual standards as well as the condi¬ 
tions under which various of the standards can or should be combined 
into profiles. 

For example, where similar services are provided by both workstation 
type application platforms and supercomputers, the same standards 
should be applied to each if possible. This would enable a greater degree 
of portability across these specialized implementations of the application 
platform. 

(7) Distributed System Scalability 

The POSIX OSE shall provide for distributed system scalability. 

Rationale: The number of distributed system components connected 
should not be limited by any structural aspects of the POSIX OSE. 

For example, in the area of network services, the OSE standards should 
be such that it is possible to construct profiles (and therefore systems) in 
which remote and local operation and utilization of information system 
resources are indistinguishable, with the exception of unavoidable 
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113 

114 

115 

116 


message transit delay. In other words, it should be possible for applica¬ 
tions to be unaware of whether the application platform on which they 
are executing is local or distributed and that lack of awareness should 
not affect their proper operation. 


117 (8) Implementation Transparency 


118 


The POSIX OSE shall provide implementation technology transparency. 


119 Rationale: The mechanism for implementation of services is not visible 

120 to the service user; i.e., only the service is visible to the service user. 


121 (9) User’s Functional Requirements 


122 The POSIX OSE shall reflect the full scope of the user’s functional require- 

123 ments, within the context of the other requirements above. 


124 

125 

126 


Rationale: The POSIX OSE will provide the context within which applica¬ 
tion software portability can be addressed and it is the set of user’s func¬ 
tional requirements that defines the scope of transportable service needs. 


127 3.2 POSIX Open System Environment Reference Model 

128 The POSIX OSE is based on a reference model with the full information system as 

129 its scope. As such, it spans the gap between requirement specification and the 

130 design of any specific information system. The reference model provides a set of 

131 conventions and concepts, mutually agreed upon between the information system 

132 user and provider communities. This common understanding is key to achieving 

133 application software portability, system interoperability, and may encourage 

134 software reuse. It will certainly allow for more compact and correct procurement 

135 specifications. 

136 The definition of this reference model is an engineering and management task 

137 and not a scientific one. There are many possible models and, while it might be 

138 interesting to contemplate an optimal one, a reference model that satisfies the 

139 requirements is all that is necessary. 

140 An information system reference model must satisfy conflicting requirements 

141 similar to those encountered in traditional architectural disciplines. The refer- 

142 ence model must be structured enough to encourage the generation and use of 

143 standards and standard components. Yet it must also be flexible enough to 

144 accommodate tailored and special purpose components necessary to meet 

145 realworld needs. 

146 The POSIX OSE Reference Model is a set of concepts, interfaces, entities, and 

147 diagrams that provides a basis for specification of standards. The POSIX OSE 

148 Reference Model will provide guidance and direction for future standardization 

149 and integration efforts. In order for the POSIX OSE to evolve and mature, it will 

iso be necessary for the reference model to provide insights into those services and 

151 capabilities for which standards do not currently exist and for which appropriate 

152 standardization activities cannot be identified. 
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153 The POSIX OSE Reference Model is described from the user perspective; i.e., the 

154 reference model records the application platform user’s perception (mental model) 

155 of the overall large distributed system used to support the user enterprise. This 

156 point of view will assure that the: 

157 — Information technology users will have the proper services to meet their 

158 requirements, and 

159 — Information technology vendor implementations will not be constrained 

160 unnecessarily. 

161 _ 



162 _ 

163 Figure 3-1 - POSIX OSE Reference Model 

164 Figure 3-1 depicts the basic elements of the POSIX Open System Environment 

165 Reference Model. These include three entities (Application Software, Application 

166 Platform, and External Environment) and two interfaces between them, identified 

167 as the Application Program Interface (API) and the External Environment Inter- 

168 face (EEI). The application platform provides API and EEI services across the 

169 associated interfaces. 

170 This model has been generalized to such a degree that it can accommodate a wide 

171 variety of general and special purpose systems. More detailed requirements exist 

172 for each service category described in Section 4. The service specification has 

173 been defined to be robust and flexible enough to allow subsets or extensions for 
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174 each category as needed. As a result, the POSIX OSE reference model is able to 

175 accommodate a variety of architectures and standardization approaches. It 

176 should be possible to show where any relevant standard fits within the reference 

177 model. 

178 Standards (in the sense of formally adopted consensus specifications) address only 

179 interfaces between entities, as well as services and supporting formats offered 

iso across those interfaces. The interface specification defines a convention adopted 

181 to represent the function offered across the interface in both directions. Note that 

182 no set of standards can, by itself, assure portability of specific applications. Appli- 

183 cations must be properly engineered with an explicit portability objective in order 

184 to achieve it. 

185 The Reference Model is not a layered model. The application platform provides 

186 services to a variety of users across both platform interfaces. A human being D 

187 invokes the platform services at the External Environment Interface. If an appli- D 

188 cation developer is the application platform user, the services offered at the appli- 

189 cation program interface (API) are invoked at the source code level. 

190 All of these features may be available locally or remotely if the system is con- 

191 nected to a larger distributed system. All other resources and objects can be con- 

192 ceptualized as being contained within the application platform. 

D 

193 Note that the actual implementation of any given system element may differ 

194 greatly from the reference model presented. The intention is to define a concep- 

195 tual reference model that the widespread design, implementation, and integration 

196 communities may assume in executing their activities. Partitioning of function 

197 for purposes of discussion or specification does not imply or endorse similar parti- 

198 tioning for design or implementation. 

199 3.2.1 Reference Model Entities and Elements 

200 Figure 3-2 expands Figure 3-1 to identify elements of the Reference Model enti- 

201 ties. For the purposes of this discussion, the term “entities” will be used when 

202 discussing the classification of items (i.e., “things”) related to application portabil- 

203 ity. The term “component” will only be used when an entity is further decom- 

204 posed into constituent parts. The application software entity is the only entity 

205 that is decomposed into components. 

206 Application Software is defined (see 2.2.2.4) as software specific to an application. 

207 It is composed of: 

208 — Programs (source code, command/script files, etc.) 

209 — Data (user data, application parameters, screen definitions, etc.), and 

210 — Documentation (online documentation only; hardcopy not included). 

211 An application program is represented by source code, produced according to a d 

212 specific programming language and a set of language bindings (i.e., API D 

213 specifications) for the required services. These specifications may be public 
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216 Figure 3-2 - POSIX OSE Reference Model — Entities 


217 standards or other open specifications. 

218 An application program may be divided into two parts: 

219 — An invariant portion of source code, requiring no change when ported, and 

220 — A variant portion of source code, which requires changes when ported. 

221 The objective of any effective application software portability method should be to D 

222 minimize the “variant” portion of the application software via creation and use of D 

223 API standards. This would ideally allow application software components to be 

224 moved to a different (but portability-standard compliant) system and run without 

225 source code modification. However, since standards exist for which strictly con- 

226 forming application software requires modification (e.g., memory requirements, 

227 processor-specific COBOL statements), this can only be approximated. 

228 Separate but related standards may be required to support the portability of each 

229 of the elements listed above. Examples of application software are the familiar 

230 word-processing, spreadsheet, or accounting packages, as developed by the consu- 

231 mer or a commercial application software developer. Each of these packages 

232 appears as an application software entity when executed on an application plat- 

233 form. 
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234 One or more applications may run on a given application platform simultane- 

235 ously, as represented by the boxes at the top of Figure 3 - 2 . Each application can 

236 be thought of as an independent application entity, communicating and synchron- 

237 izing with other applications, if necessary, via a variety of communications 

238 mechanisms. 

239 The Application Platform is defined (see 2 . 2 . 2 . 2 ) as the set of resources that sup- 

240 port the services on which an application or application software will run. It pro- 

241 vides services at its interfaces that, as much as possible, make the 

242 implementation-specific characteristics of the platform transparent to the applica- 

243 tion software. 

244 In order to assure system integrity and consistency, application software entities 

245 competing for application platform resources must access all resources via service 

246 requests across the API. Examples of application platform elements could include 

247 an operating system kernel, a realtime monitor program, and all hardware and 

248 peripheral drivers. 

249 The application platform concept does not imply or constrain any specific imple- 

250 mentation beyond the basic requirement to supply services at the interfaces. For 

251 example, the platform might be a single processor shared by a group of applica- 

252 tions, or it might be a large distributed system with each application dedicated to 

253 a single processor. (See 3 . 2 . 4 .) 

254 The application platform for systems built to the POSIX OSE will differ greatly 

255 depending upon the requirements of the system and its intended use. It is 

256 expected that application platforms defined to be consistent with the POSIX OSE 

257 will not necessarily provide all the features discussed here, but will use tailored 

258 subsets for a particular set of application software. 

259 The External Environment contains the external entities with which the applica- 

260 tion platform exchanges information. These entities are classified into the gen- 

261 eral categories of human users, information interchange entities, and communica- 

262 tions entities. 

263 Human users are not further classified, but are treated as an abstract, or average, 

264 person. Information interchange entities include removable disk packs, floppy 

265 disks, and security badges. Communications entities include phone lines, local 

266 area networks, and packet switching equipment 

267 3.2.2 Reference Model Interfaces 

268 Figure 3-3 expands Figure 3-1 to identify the services available at the reference 

269 model interfaces. 

270 Between these three classes of entities there are two types of interface where 

271 standards and other open system specifications are required to enable application 

272 software portability and interoperability. These two interface types are labeled as 

273 the Application Program Interface (API) and the External Environment Interface 

274 (EEI). 
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277 Figure 3-3 - POSIX OSE Reference Model — Interfaces 


278 3.2.2.1 External Environment Interface (EEI) 

279 The External Environment Interface is defined (see 2 . 2 . 2 . 9 ) as the interface 

280 between the application platform and the external environment across which 

281 information is exchanged. It is defined primarily in support of system and appli- 

282 cation software interoperability. User and data portability are directly provided 

283 by the EEI, but application software portability also is indirectly supported by 

284 reference to common concepts linking specifications at both interfaces. The ser- 

285 vices available at the EEI comprise: 

286 — Human/Computer Interaction Services 

287 — Information Services 

288 — Communications Services 

289 The Human/Computer Interaction EEI is the boundary across which physical 

290 interaction between the human being and the application platform takes place. 

291 Examples of this type of interface include CRT displays, keyboards, mice, and 

292 audio input/output devices. Standardization at this interface will allow users to 

293 access the services of compliant systems without costly retraining. 
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294 The Information Services EEI defines a boundary across which external, per- 

295 sistent storage service is provided, where only the format and syntax is required D 

296 to be specified for data portability and interoperability. 

297 The Communications Services EEI provides access to services for interaction 

298 between internal application software entities and application platform external 

299 entities, such as application software entities on other application platforms, 

300 external data transport facilities, and devices. The services provided are those 

301 where protocol state, syntax, and format all must be standardized for application 

302 interoperability. 


303 3.2.2.2 Application Program Interface (API) 


304 The Application Program Interface (API) is defined (see 2 . 2 . 2 . 3 ) as the interface 

305 between the application software and the application platform across which all 

306 services are provided. It is defined primarily in support of application portability, 

307 but system and application software interoperability also are supported via the 

308 communications services API. 

309 The POSIX OSE API is a combination of a number of standards-based interfaces. 

310 It can be thought of as a bookshelf containing several standards-based APIs, with 

3 11 each API a separate book on the bookshelf. 

312 The POSIX OSE API specifies a complete interface between the application 

313 software and the underlying application platform, and may be divided into the fol- 

314 lowing parts: 

315 — Human/Computer Interaction Services API 

316 — Information Services API 

317 — Communications Services API 

318 — System Services API 

319 The first three APIs listed are required to provide the application software with 

320 access to services associated with each of the external environment entities. 


321 The fourth API is required to provide access to services associated with the appli- 

322 cation platform internal resources, identified as the System Services API. This 

323 interface may be divided into two types of specifications; i.e., Language Service 

324 and System Services API specifications. 

325 Definitions of services at the API take the form of programming-language 

326 specifications, language-independent service specifications, and language bind- 

327 ings for the service specifications. These specifications may be described as fol- d 

328 lows: D 


329 

330 

331 


( 1 ) Those traditionally associated with the language specifications, such as 
program control (if ... then ... else), math functions, string manipula¬ 
tion, etc., defined as the programming language API, and 


332 ( 2 ) Services provided by the underlying application platform defined 

333 independent of language, such as interprocess communications, 
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334 interobject messages, access to the user interface, and data storage, d 

335 Specifications of for these services are defined independently of any pro- D 

336 gramming language, and are identified as language-independent service D 

337 specifications . d 

338 (3) The language-independent service specifications are translated into D 

339 language-specific specifications used by programmers in writing applica- D 

340 tions. These specifications provide access to the services using methods d 

341 consistent with a specific programming language. Such language-specific D 

342 specifications are called language-binding APIs . D 

343 Creation of a language-independent service specification facilitates the manage- 

344 ment and development of consistent language binding standards. The language- 

345 binding specifications are used directly by programmers and application platform 

346 suppliers in implementing application software and platforms. 


347 The “programming language”/“language binding” dichotomy may be a result of 

348 the way Information Technology standards are currently developed. Program- 

349 ming language specifications are developed with the goal of being “system 

350 independent” (e.g., C, COBOL, FORTRAN, etc.). Language Binding specifications 

351 (e.g., POSIX.l { 2 }, MOSI, etc.) are being translated into “language-independent” 

352 specifications, with one or more bindings for specific languages. 

353 3.2.3 EEI-API Service Relationships 

354 The relationships between similarly named services provided at the API and the D 

355 EEI are not simple one-to-one relationships. For example, a data storage service d 

356 interface may provide an application with transparent access to a remote file via D 

357 network services. In this case, the completion of the data storage service provided d 

358 at the API is dependent upon, and can be thought of as having been “translated” D 

359 into, communication services provided at the EEI. D 

360 Fortunately, it is not essential for the purpose of satisfying the requirements of 

361 the POSIX OSE to specify these relationships in detail. In fact, a detailed 

362 definition could unnecessarily constrain the implementation. A given implemen- 

363 tation of the application platform will define the relationship between the API and 

364 EEI in different ways. 

365 3.2.4 POSIX OSE-Based Distributed Systems D 

366 In a distributed environment, multiple application platforms may interact by way 

367 of a network external to the platforms, but connected to them via the communica- 

368 tions EEI, as in Figure 3 - 4 . For an application software entity to gain access to 

369 the EEI services, communications services are requested at the API. The imple- 

370 mentation of the application platform translates these API requests into appropri- 

371 ate action at the EEI. 

372 Communication occurs between application platforms via external entities that 

373 implement the data transport function. These can use a wide variety of imple- 

374 mentation methods and protocols, providing access to distributed data and 
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376 _ 

377 Figure 3-4 - POSIX OSE Reference Model — Distributed Systems 

378 services via the network. 

379 Distributed Systems are manifest in this model primarily through the use of the 

380 distributed system network services API. As can be seen in Figure 3-5, distri- 

381 buted systems are a refinement of the POSIX Network Environment Model shown 

382 in Figure 4-4. As such, a perceived Application Platform may in fact be comprised 

383 of several (or many) individual application platforms. However, in the distributed D 

384 environment, they operate and are viewed as a single entity by the using applica- 

385 tions. Within this extended application platform are the embedded network ser- 

386 vices necessary for the elements of a distributed environment to function. 

387 Within the distributed environment, network access between the platforms that 

388 make up the “perceived” application platform are handled using the Distributed 

389 Systems Network Services APIs. Network services for access between “perceived” 

390 application platforms will use the Network Services EEI between the platforms. 


391 3.3 POSIX Open System Environment Services 

392 This guide defines a uniform set of standard services provided to users of applica- 

393 tion platforms in support of POSIX objectives of application portability and system 

394 interoperability. These services are available to users across specified interfaces 

395 keyed to the POSIX reference model defined in 3.2. 

396 The POSIX OSE services are divided into categories described by the clauses in D 

397 Section 4. Each category begins by defining a more detailed and specialized ver- 

398 sion of the OSE reference model (see 3.2) to provide context for service 
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399 



400 _ 

401 Figure 3-5 - Distributed System Environment Model 

402 specification. Services and associated standards are then defined for each d 

403 category. Finally, POSIX OSE Cross-Category Services affecting each category are D 

404 discussed. 

405 The service descriptions for each category are intended to be complete and not 

406 merely representative. Further refinement through successive releases of this 

407 document will lead to a complete specification. 


408 3.4 POSIX Open System Environment Standards 

409 The identification of a complete, consistent suite of standards for the POSIX OSE 

410 will, by necessity, draw from many forums. One of the criteria for judging corn- 

411 pleteness is the satisfaction of the full range of services required by the applica- 

412 tion platform user. The factors used to select standards will be described followed 

413 by the selection precedence. 

414 Note that while the services are stated with a clear partitioning in mind, the stan- 

415 dards reflect the current partitioning. These standards were created within 

416 disparate organizations and projects, which were in many cases carried out in iso- 

417 lation from the others. As a result, mapping of services to standards is not a sim- 

418 pie relationship. 
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419 3.4.1 Factors in Standards Selection 


420 The selection criteria for standards to be included in the POSIX OSE are based 

421 upon four concepts. Those concepts are Those concepts are openness, Stage of 

422 Completion, stability, Geographic Scope of Consensus, Functional Scope 

423 Addressed within this guide, Consistency with POSIX. 1 {2}, and Availability for 

424 Unencumbered Implementation. 


425 (1) Openness 


426 

427 

428 

429 

430 


Standards development organizations can differ from one another by vir¬ 
tue of their “openness.” That is, some standards development bodies util¬ 
ize an open for um for the development of standards while other bodies 
use a closed forum. The result is a varying degree of consensus in the 
technical content of the standards across development bodies. 


431 

432 

433 


As a general rule, standards developed by accredited standards develop¬ 
ment organizations (all of which use an open forum) are preferred over 
those standards developed by bodies using a closed forum. 


434 (2) Stage of Completion 


435 

436 

437 

438 

439 


Another factor involved in the selection of standards for inclusion in the 
POSIX OSE is “stage of completion.” That is, there is a standards 
development life cycle process whose effects need to be taken into 
account. Most standards follow a sequence from approved development, 
through draft, and on to approved standard. 


440 As a general rule, where choices were made among standards, the more 

441 complete standards were favored. 


442 (3) Stability 


443 

444 

445 

446 


A third factor in determining which standards are included in the POSIX 
OSE is stability. This factor refers to anticipated change in the standard 
over time. This change may expand or contract the technical coverage of 
the standard. 


447 As a general rule the more stable standards are preferred over those sub- 

448 ject to change. 


449 (4) Geographic Scope of Consensus 


450 

451 

452 

453 

454 

455 

456 

457 


There are differences among standards development bodies with respect 
to the scope of their geographic consensus. Some among those bodies are 
formal standards bodies (i.e., accredited as standards developers by a 
recognized body). It is typical for those bodies to be authorized to develop 
standards for a particular technical topic and have their standards appli¬ 
cable to some defined geographic area. Formal standards development 
bodies are typically empowered to develop standards for either interna¬ 
tional, regional or national standards coverage. 


458 The general rule applied in the selection of standards for inclusion in the 

459 POSIX Open System Environment is to select standards developed by 
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460 those bodies that have the greatest scope of coverage. This results in a 

461 precedence for standards selection of international, followed by regional, 

462 followed by national body developed standards. 

463 (5) Functional Scope Addressed within this guide 

464 A specification is listed only if it addresses some service requirement 

465 listed in this guide. Standards and/or specifications listed are not, how- 

466 ever, limited to one per set of services. 

467 (6) Consistency with POSIX.1 {2} 

468 Standards listed in this guide are suitable for inclusion in a profile with 

469 POSIX.1 {2}, and do not contradict that standard in any way. 

470 (7) Availability for Unencumbered Implementation 

471 A standard or specification is listed only if it is available for implementa- 

472 tion to the specification and distribution of that implementation is unen- 

473 cumbered. The specification qualifies for inclusion in the guide even if 

474 the document itself is a salable item. 

475 3.4.2 Selection Precedence 

476 The list below shows the precedence of standards and specifications as used for 

477 inclusion in the POSIX OSE. The order from top to bottom is from most to least 

478 preferred. 

479 (1) Approved standards developed by accredited international bodies 

480 (2) Approved standards developed by accredited regional bodies 

481 (3) Approved standards developed by accredited national bodies 

482 (4) Draft standards developed by accredited international bodies 

483 (5) Draft standards developed by accredited regional bodies 

484 (6) Draft standards developed by accredited national bodies. 

485 (7) Recognized de facto standards and specifications developed by nonac- 

486 credited bodies using an open forum 

487 (8) Approved standards and specifications developed by nonaccredited inter- 

488 national standards bodies using a closed forum 

489 (9) Approved standards and specifications developed by nonaccredited 

490 national standards bodies using a closed forum. 

491 Standards projects for which there is no draft or approved standard are never 

492 selected for inclusion in the POSIX OSE. 

493 “Equivalent” or “derived” standards lower in the precedence hierarchy are corre- 

494 lated in an annex. FES: Do we still want to do this? Only the highest precedence 

495 specification is listed or discussed in the main text. 


Copyright © 1991 IEEE. All rights reserved. 

This is an unapproved IEEE Standards Draft, subject to change. 


3.4 POSIX Open System Environment Standards 


29 



P1003.0/D13 


GUIDE TO THE POSIX OPEN SYSTEMS 


496 This guide only cites government and de facto standards and specifications in dis- 

497 cussion of gaps in available standards. 


498 3.5 POSIX Open System Environment Profiles 

499 The results of Open System specification projects are collected into an expanding 

500 set of “Base Standards,” addressing a growing subset of functional requirements. 

501 Profile projects then select among these base standards to create a tailored, con- 

502 sistent set of standards addressing a more specific type (or instance) of system or 

503 set of application software. Profiles satisfy the requirements of application 

504 “domains” such as office or industrial automation, transaction processing, or real- 

505 time control systems. 

506 This framework provides a way to characterize the functionality of profile activi- 

507 ties. The current OSI profiles tend to focus strictly on the communications EEI. D 

508 Other profiles might focus on a single component or span multiple interface types. 


509 3.6 Application Platform Implementation Considerations 

510 HLJ: All instances of “System Integration Interface” in this clause have been D 

511 changed to “System Internal Interface” without further diff marks. D 

512 Profile writers need to be aware that in an open system environment, the applica- 

513 tion platform can be decomposed into independently procurable components. 

514 While standards are interface specifications, and as such are independent of 

515 implementation, there are aspects of platform implementation or construction 

516 that may affect the specification of standards, and that profile writers may want 

517 to address. 

518 For each case, the portion of the application platform that implements any partic- 

519 ular independently procurable service is described as the service component. 

520 Figure 3-6 shows an application platform made up of several service components. 

521 If components interact, the specification of the interface between service corn- 

522 ponents within the application platform may be standardized or nonstandard 

523 (including proprietary). 

524 An intercomponent interface is labeled in Figure 3-6 as “System Internal Inter- 

525 face” because it may be used to assemble an application platform from multiple 

526 components. Figure 3-6 shows how a System Internal Interface is shown in the 

527 reference model. 

528 A standards-based SII between the application platform service components 

529 addresses portability and interoperability of the application platform service com- 

530 ponents, not portability and interoperability of application software and systems. 

531 Development of an SII would also require a consensus to emerge on the “best” 

532 design and implementation of system software/hardware. Very little consensus 

533 has developed on the partitioning of the platform into components and consequent 
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536 Figure 3-6 - Service Components and Interfaces 

537 allocation of function to each. In fact, this aspect of system design has been in a 

538 constant and accelerating state of innovation for decades. One of the major objec- 

539 tives of the API is to provide a more stable interface that decouples application 

540 software from the constantly changing platform. This enables the migration of 

541 application software to platforms based on constantly upgraded technology. (See 

542 3.1 “Accommodation of New Information System Technology”.) 

543 The relationship and services exchanged among the components may be quite 

544 complex and varied in different implementations. This complexity and variety 

545 would, of necessity, be reflected in an SII. It would not, however, be visible to the 

546 application software at the API, since one of the major objectives of the API is to 

547 hide this complexity. (See 3.1 “Implementation Transparency”.) 

548 Since SII specifications 

549 — do not affect application portability and interoperability, and 

550 — do not affect specification of the API and EEI, and 

551 — are primarily driven by specific implementations of the application plat- 

552 form, 

553 SII specification is beyond the scope of this guide. D 

554 Specification of SII in this guide would represent an unnecessary constraint on the 

555 implementation of the application platform, and are unnecessary for the 

556 specification of the API and EEI. 

557 There are a number of ways which the Application Platform can be divided into 

558 separate service components. The main decomposition methods are division, 
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559 layering, and redirection. These methods are indistinguishable to the application 

560 software and external entities, in that they all interface to the application plat- 

561 form via the API and EEI, respectively. They assume a starting base application 

562 platform, which provides a subset of the required services. 


563 3.6.1 Subdivision 

564 In this commonly used method, the application platform is simply subdivided into 

565 a base and one or more service components. See Figure 3-7. 

566 _ 
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568 Figure 3-7 - Application Platform Implementation — Subdivision 

569 One possible implementation of this is to link the appropriate service modules 

570 directly into the system kernel. 

571 The internal interfaces used in this method are normally proprietary, and hence 

572 normally imply that both components will come from the same vendor. 

573 In this case the Application Platform and the Application Platform Base are the 

574 same entity. 


575 3.6.2 Layering 

576 In layering, the service is interposed as a layer between the application software 

577 and the base application platform. See Figure 3-8. 

578 This is the most common method of supplying a service component that is 

579 independent of the base. One possible implementation is to provide the service 

580 component as a set of library routines. 

581 Whether the interface between the service layer and the base application platform 

582 conforms to any standards affects the portability of the service component. Note 

583 that specifying a standard API for this interface guarantees only that this 
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586 Figure 3-8 - Application Platform Decomposition II — Layering 

587 _ 


r 
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589 Figure 3-9 - Application Platform Decomposition III — Redirection 


590 component will be portable at the source level. 
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591 3.6.3 Redirection 

592 Redirection allows a service component to ask the base application platform to 

593 redirect all requests for that type of service to the service component. See 

594 Figure 3-9. Possible examples of such services are device drivers, network proto- 

595 col handlers, and database engines. 

596 In actual implementation, the service component may or may not be a separate 

597 process. Possible implementations are: dynamically loadable kernel modules, 

598 library routines layered over IPC, and lightweight kernel processes. 

599 Note that there are three interfaces. The application software normally sees a 

600 complete, standard API to the base. The service component has two interfaces— 

60 1 one to effect the redirection, and one to provide base services to the service appli- 

602 cation software entity. Considerations for portability discussed under Layering 

603 also apply here. 

604 Note also that no POSIX standardization activity currently exists for the redirec- 

605 tion interface. 
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Section 4: POSIX Open System Environment Services 


1 Responsibility: Fritz Schulz 

2 This section describes the services required in support of the objectives identified 

3 in this guide. The services are grouped in major categories defined in Section 3, 

4 with more detailed breakdowns within each category as appropriate. These 

5 categories are: 

6 Fundamental System Services 

7 4.1 Language Services 

8 4.2 System Services 

9 Communications Services 

10 4.3 Network Services 

11 Information Services 


12 

4.4 

Database Services 

13 

4.5 

Data Interchange Services 

14 

Human-Computer Interaction Services 

15 

4.6 

Windowing System Services 

16 

4.7 

Graphic Services 

17 

4.8 

Character-Based User Interface Services 

18 

4.9 

User Command Interface Services 


D 


19 Domain Services 


20 4.10 Transaction Processing Services d 

21 4.11 Software Development Environment Services 

22 Criteria used to partition services are outlined in 3.2, and discussed at the begin- 

23 ning of each clause. The discussion for each of the service category subclauses fol- 

24 lows the same outline, and is as follows: 

25 4.71.1 

26 4.71.2 Overview and Rationale, Scope 

27 This text introduces the scope of this service category, and the cri- 

28 teria used to identify the services within it. 
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29 4./Z.3 Reference Model 


30 

31 

32 

33 


This subclause builds on the model of clause 3.2 and gives additional 
detail related to the interfaces and services discussed there. An 
optional subclause may discuss implementation considerations, simi¬ 
lar to the discussion of 3.6. 


34 


4 ./1.4 Service Requirements 


35 

36 


This text provides the definition of service requirements within the 
scope described in A.n.2. 


37 


4 ./1.5 Standards, Specifications, and Gaps 


38 

39 

40 


A table lists the standards and specifications available to meet the 
service requirements listed in 4.71.4. This is followed by a brief dis¬ 
cussion of services for which standards are not available. 


41 4.71.5.1 Current Standards 


42 

43 

44 

45 

46 


The following subclauses cite existing specifications that have been 
approved as standards by accredited standards bodies, in the order D 
of precedence identified in 3.4.2. When service requirements are D 
satisfied at a higher precedence level, specifications at a lower level d 
are not listed. d 


47 

48 

49 

50 

51 

52 

53 

54 

55 

56 

57 

58 

59 

60 
61 


4.71.5.2 Emerging Standards 

The following subclauses list specifications and/or activities that 
address the functional areas within the 4.71 section, but which have 
not yet been completed. Where a group or activity is cited, the char- d 
ter of the group may address the functionality, but it is possible that 
a draft may not be available. Only those services not currently 
addressed by existing standards are to be discussed in this sub¬ 
clause. It is expected that documents will migrate from 4.71.5.2 to 
4.71.5.1 as they complete the consensus process. 

D 

4.71.5.3 Gaps in Available Standards 

This subclause identifies those service requirements that have not 
been satisfied by existing or emerging standards. If all service 
requirements in this category have been met by existing or emerging 
standards, this subclause will be empty. Text in this subclause will 
be minimal. 


62 4.71.5.3.1 Public Specifications 


63 

64 

65 

66 


This subclause lists any specification outside of the formal standards 
community that is available to anyone (e.g., no membership 
required) for implementation and distribution (including sale) 
without restriction, including all government and de facto standards. 
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67 

4.71.5.3.2 

Unsatisfied Service Requirements 

68 

69 

70 


This subclause lists the services for which no specification has been 
cited in this guide. Products may be cited here to illustrate capabili¬ 
ties that are not addressed by standards. 

71 

4.71.6 

POSIX OSE Cross-Category Services 

72 

73 


This subclause contains any discussion of the Cross-Category Ser¬ 
vices in Section 5 that is specific to subclause 4 .ti. 

74 

4.71.7 

Related Standards 

75 

76 

77 


This subclause is optional and may identify interdependencies 
among standards that should be taken into account when selecting 
among them. 

78 

4.71.8 

Open Issues 

79 

80 


This subclause is optional and may identify issues under discussion 
in the open systems community. 
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81 4.1 Language Services 

82 Responsibility: Don Folland 

83 4.1.1 Overview and Rationale 

84 While a consistent interface to the operating system is essential for applications 

85 portability, the application will have been developed using language and system 

86 development tools that, in turn, require to be supported by standards to achieve 

87 source code portability. 

88 Those responsible for system or software development will wish to write programs 

89 in code supported by an international standard and compile the code using a com- 

90 piler that has a certificate of conformance issued by an accredited test center. 

91 Noncompliant extensions must be avoided if applications portability is to be main- 

92 tained. Compilers should identify nonstandard-compliant code. 

93 The languages that have been identified in this document are those seen to be in 

94 most popular use today for software development. The POSIX.2 shell command D 

95 language is discussed in 4.9. The standards identified are the most widely recog- D 

96 nized today, with significant use in the Information Technology industry on a 

97 broad range of processors, or where a large installed base of a particular version 

98 is known to exist. 

99 4.1.2 Scope 

100 The services described in this clause cover the most widely used third-generation 

101 computer languages in use today for the development of applications; i.e., the 

102 languages used to write application programs. Fourth-generation languages are 

103 not currently addressed in this guide. In order for a program to address an API to 

104 the services described in other clauses of this guide, an appropriate language 

105 binding to that interface is required. References to those bindings will be found in 

106 the clause describing the relevant service. 

107 4.1.3 Reference Model 

108 This subclause identifies the entities and interfaces supporting language services. 

109 The reference model based on the reference model in Figure 3-1 is illustrated in 

no Figure 4-1, but because the language services directly support the binding of the 

in applications to the API, there is no EEI. However, the EEI is shown in Figure 4-1 

112 for consistency. 

113 At the simplistic level, the programmer developing an application that requires 

114 only basic operating system services will use a compiler that meets both the fun- 

115 damental language standard (e.g., ISO 1989: 1985 for COBOL, ISO 1359: 1990 for d 

116 Fortran) and the binding established for the relevant system calls in POSIX.1 {2}. 

117 As identified in 4.10, an application program may also require database services 

ns that will be provided by the Database Manager API. The database vendor will 
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Language Services API: 

— Arithmetic Operation 

— Code structure 

— Data definition 

— Data representation 

— Error handling 

— I/O operations 

— Math functions 

— Program control logic 


External Environment 



120 _ 

121 Figure 4-1 - Language Service Reference Model 


122 offer an API to meet the requirements for the popular programming languages. 

123 In a POSIX Open System Environment the intention is that support is provided 

124 for all languages identified in 4.1.4. 


125 4.1.4 Service Requirements 

126 Programming language services provide the basic syntax and semantic definition 

127 for use by a software developer to describe the desired application software func- 

128 tion. While most clauses in this guide provide a comprehensive list of services, in 

129 the case of languages many services are a unique function of the language 

130 specification. Rather than extend the size of this guide, the detail is more 

131 appropriately found in the relevant language manuals and supporting standards. 

132 4.1.4.1 Application Program Services 

133 Programmers require the ability to compile a program in the language of their D 

134 choice. The selection of a particular programming language for the development 

135 of an application may depend on a variety of factors, including the capability to 

136 provide some of the functions listed here: 

137 — Arithmetic operation 

138 — Code structure 

139 — Data definition 

140 — Data representation 

141 — Error handling 
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142 — I/O operations 

143 — Mathematical functions 

144 — Program control logic 

145 The programming languages identified in this clause are: 

146 Ada 

147 APL 

148 BASIC 

149 C 

150 C++ 

151 COBOL 

152 Common LISP 

153 FORTRAN 

154 Pascal 

155 PL/1 

156 Prolog 

157 As well as making reference to the relevant language standard, where a program- d 

158 mer requires to call other services, e.g., seeks access to graphics kernel system, it d 

159 will be necessary to refer to the relevant language binding to those services. D 

160 Language bindings are identified in the Standards subclause, A.n.10, of each ser- d 

161 vice clause in Chapter 4. d 

162 4.1.4.1.1 Ada 

163 Ada is a procedural language based on the Pascal programming language. It is 

164 capable of processing both numerical and textual data, and has the key attributes 

165 of: 

166 — Strong data typing 

167 — Data abstraction 

168 — Structured constructs 

169 — Multitasking 

170 — Concurrent processing 

171 Although Ada was developed initially for military purposes, it is considered suit- 

172 able for a variety of business and industrial applications. 

173 4.1.4.1.2 APL 

174 APL is a language and interactive programming environment oriented around 

175 multidimensional arrays of characters and numbers. It uses an extremely corn- 

176 pact notation based on powerful primitive functions and function-combining 

177 operators. Revisions to the language are in preparation to permit single array 

178 elements to contain arrays. 
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179 4.1.4.1.3 BASIC 

iso BASIC is an interactive and procedural language with some similarity to FOR- 

181 TRAN. It is readily learned by non-computer-literate individuals. Commonly 

182 used for educational purposes, it has also been adopted in a variety of business 

183 and commercial applications running on small business systems. BASIC offers: 

184 — Conversational statements 

185 — Free style input 

186 — Segmentation of complex statements 

187 — Six significant digits of accuracy 

188 — Mathematical functions 

189 4.1.4.1.4 C 

190 C is a general purpose procedural language that was developed for the UNIX 

191 operating system. It offers the control and data structure of a high-level language 

192 and the efficiency of primitive operators that have made it very suitable for sys- 

193 tern programming. 

194 4.1.4.1.5 C++ 

195 C++ has evolved as a superset of C and may be viewed as a procedural language, 

196 while at the same time offering the capability for object-oriented programming. 

197 The concept of an object-oriented language is to define data objects that include 

198 sets of operations to manipulate the data, and so direct these objects to apply the 

199 necessary operations which comprise the application. 

200 4.1.4.1.6 COBOL 

201 COBOL is a procedural language designed originally to meet the needs of busi- 

202 ness. It permits use of natural words and phrases, enabling the language to be 

203 adopted by non-technical writers with a basic appreciation of information process- 

204 ing. The language offers file organization features, variable data length, 

205 input/output procedures, and report generation. 

206 4.1.4.1.7 Common LISP 

207 LISP is an interactive nonprocedural language. The basic entity is the symbolic 

208 expression which is either an atomic symbol or a list structure. A list is a set of 

209 items in a specific order. Lists can be variable length and dynamically adjusted; 

210 the items can be of different type. 

211 4.1.4.1.8 FORTRAN 

212 Though originally developed for processing scientific problems the language is 

213 widely used in commercial and educational applications. It is a procedural 

214 language whose grammar, symbols, rules, and syntax are simple mathematical 

215 and English-language conventions. Its focus is on numerical computation, using 
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216 simple concise statements, operating on small amounts of input data and little 

217 text. 

218 4.1.4.1.9 Pascal 

219 This is a procedural language that is particularly effective in structured program- 

220 ming and was designed to help programmers in rapid error detection. It is highly 

221 efficient, handling both numerical and textual data. It is considered very suitable 

222 for small system applications such as typesetting, editorial work, computer aided D 

223 design (CAD), and manufacturing processes. D 

224 4.1.4.1.10 PL/1 

225 This is a procedural language introduced to offer in one language the strengths of 

226 both COBOL and FORTRAN; i.e., serving both the business and scientific communi- 

227 ties. It has the FORTRAN strength of simple statements, coupled with the ability, 

228 as in COBOL, to manipulate data and organize files. It is block structured, facili- 

229 tating good programming techniques. 

230 4.1.4.1.11 Prolog 

231 This language, like LISP, is nonprocedural and has an emphasis on description 

232 rather than on action. It is described as pattern-directed role-based programming 

233 using definitions of conditions established within the program to satisfy a query. 

234 It is of particular value in applications of artificial intelligence, for constructing 

235 expert or knowledge-based systems. 

236 4.1.4.2 External Environment Interface Services 

237 Not applicable. 

238 4.1.4.3 Interapplication Software Entity Services 

239 Not applicable. 

240 4.1.4.4 Language Resource Management Services 

241 Not applicable. 

242 4.1.5 Standards, Specifications, and Gaps 

243 4.1.5.1 Current Standards in the POSIX OSE 

244 Most of the languages referenced in this clause are supported by International 

245 Standards; Table 4-1 provides a summary. 


Copyright © 1991 IEEE. All rights reserved. 

This is an unapproved IEEE Standards Draft, subject to change. 


4.1 Language Services 


43 



P1003.0/D13 


GUIDE TO THE POSIX OPEN SYSTEMS 


246 Table 4-1 - Language Standards Activities 

247 _ 


248 

Service 

Specification 

Subclause 

249 

Ada 

ISO 8652 

4.1.5.1.1 

250 

APL 

ISO 8485 

4.1.5.1.1 

251 

BASIC 

ISO 6373 

4.1.5.1.1 

252 

C 

ISO/IEC 9899 

4.1.5.1.1 

253 

C++ 

n/a 

4.1.5.3.2 

254 

COBOL 

ISO 1989 

4.1.5.1.1 

255 

Common LISP 

n/a 

4.1.5.3.2 

256 

FORTRAN 

ISO 1539 

4.1.5.1.1 

257 

Pascal 

ISO 7185 

4.1.5.1.1 

258 

PL/1 

ISO 6160 

4.1.5.1.1 

259 


ISO 6522 

4.1.5.1.1 

260 

261 

PROLOG 

n/a 

4.1.5.3.2 


262 4.1.5.1.1 International Standards 

263 Ada 

264 ISO 8652: 1987 is the current version of the international standard for Ada, which 

265 was an endorsement of the ANSI standard 1815A-1983. 

266 APL 

267 ISO 8485 is the current version of the international standard for APL. 

268 BASIC 

269 ISO 6373: 1984 is the current version of the international standard for minimal 

270 BASIC. 

271 C 

272 ISO/IEC 9899 is the current version of the international standard for the C 

273 language. 

274 COBOL 

275 ISO 1989: 1985 is the latest version of the international standard for COBOL, 

276 which was an endorsement of the ANSI standard X3.23-1985. An Addendum is in 

277 process at present entitled “Intrinsic function module.” 


Copyright © 1991 IEEE. All rights reserved. 

This is an unapproved IEEE Standards Draft, subject to change. 


44 


4 POSIX Open System Environment Services 



ENVIRONMENT INTERIM DOCUMENT 


P1003.0/D13 


278 Fortran D 

279 ISO 1539: 1990 is the latest revision of the international standard for Fortran. D 

280 Pascal 

281 ISO 7185: 1983 is the current version of the international standard for Pascal, 

282 which was an endorsement of the British standard BS 6192-1982. 

283 PL/1 

284 ISO 6160: 1979 is the current version of the international standard for PL/1, which 

285 was an endorsement of the ANSI standard X3.53-1976. ISO 6522: 1985 is the 

286 current version of the international standard for a General Purpose subset of 

287 PL/1, which is an endorsement of ANSI standard X3.74-1981. A revision of this 

288 standard is at Draft IS stage. 

289 4.1.5.1.2 Regional Standards 

290 4.1.5.1.3 National Standards 

291 4.1.5.2 Emerging Standards in the POSIX OSE 

292 4.1.5.2.1 International Standards 

293 BASIC 

294 DP 10279 is a proposal for Full BASIC. 

295 Pascal 

296 DIS 10206 is a draft international standard for extended Pascal. 

297 4.1.5.2.2 Regional Standards 

298 4.1.5.2.3 National Standards 

299 4.1.5.3 Gaps in Available Standards 

300 4.1.5.3.1 Standards and Specifications outside the POSIX OSE 

301 4.1.5.3.2 Unsatisfied Service Requirements 

302 There is a requirement for standardization of the following languages: 

303 C++ 

304 LISP 

305 Prolog 
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306 4.1.6 OSE Cross-Category Services 

307 Not applicable. d 

308 4.1.7 Related Standards 

309 Many of the services within the POSIX OSE require APIs with bindings to 

310 languages identified in this clause; e.g., Graphics, Database. Reference to the 

311 particular language binding standard is to be found in the relevant service clause. 

312 4.1.8 Open Issues 

313 While there are occasional calls for 4GL standards, there has been little effort 

314 applied so far. 
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315 4.2 System Services 

316 Responsibility: Patricia Oberndorf D 

317 4.2.1 Overview and Rationale 

318 This clause describes the system services component of the application platform. 

319 It presents a reference model for this component and describes the services pro- 

320 vided to application software. Those services are those usually considered as part 

321 of an operating system or executive and also those services that may be provided 

322 by system level entities such as spoolers and device drivers. Standards, current 

323 and emerging, that specify the interface to those system services are also 

324 described. 

325 System services are a key component of the application platform and represent 

326 the focus of the IEEE effort to produce POSIX base standards. A common set of 

327 system services provides support for the portability and the interoperability of 

328 application software. While other common services can aid application reuse, sys- 

329 tern services are those that are common to the largest number of applications. 

330 4.2.2 Scope 

331 System services cover those features that users have come to expect from operat- 

332 ing systems or executives. They cover the areas of process management, file 

333 management, input/output, memory management, and print spoolers. Because 

334 there is a wide variety of platform users, ranging from large general purpose 

335 time-shared systems to small time-critical, special-purpose systems, services such 

336 as timers and clocks, event management, logical device drivers, and system 

337 initialization/reinitialization are included. Services related to distributed systems 

338 are also discussed, since application software sees these capabilities through the 

339 platform. D 

340 4.2.3 POSIX OSE System Services Reference Model d 

341 4.2.3.1 Reference Model D 

342 This subclause identifies the entities and interfaces specific to the system services 

343 of the POSIX OSE. The reference model presented here is consistent with and 

344 expands upon the reference model of Section 3. It provides the context for the dis- 

345 cussion of System Services in this clause. The basis System Services model is d 

346 shown in Figure 4-2. D 

347 This clause describes the system services portion of the application platform as 

348 viewed by a software developer (not necessarily the viewpoint of the end user). 

349 This view corresponds to the program design level of abstraction. 

350 The system services API provides the interface between the application software 

351 and the system services from the source code point of view. The API defines the 
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Application Software | 

System Services API: 

— Process Management Services 
— Task Management Services 
— Environment Services 
— Node Internal Comm and Sync Services 
— Generalized I/O Services 
— File Oriented Services 
— Event, Error, and Exception Mgmt Services 
— Time Services 
— Memory Management Services 
— Logical Naming Services 
— System Init, Re-lnit, and Shutdown Services 
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354 Figure 4-2 - System Services Reference Model 

355 program designer’s means of accessing the functions, objects, and services of the 

356 system. D 

357 In order for the platform to protect system integrity and ensure system database 

358 consistency, application software competing for system resources must access all 

359 system resources via system service requests. The formal definition of these 

360 requests (or system calls) defines the system services portion of the API. 

361 All of the system services may be available locally or remotely. Some of the sys- 

362 tern services may be performed remotely if the system is a distributed system 

363 with multiple processor nodes. Such distribution is not reflected in Figure 4-2 

364 because it is transparent to users of the System Services. 

365 The platform’s device drivers and other software entities are seen as being avail- d 

366 able to an application program via invocation of the system services. Local dev- d 

367 ices include sensors, effectors, and connections to independent computing sys- D 

368 terns. The local devices themselves are a part of the external entities element of 

369 the system services reference model. The interfaces used by the application 

370 software are the logical device interfaces and are part of the system services. It 

371 should be noted that, even though the device drivers are represented within the 

372 system services portion of the application platform and the devices themselves are 

373 represented within the external entities, there is no unique system service inter- 

374 face illustrated at the EEI in Figure 3-3. This is not an oversight; it is due to the 

375 belief that such interfaces are not within the scope of this guide. 

376 4.2.3.2 Implementation Aspects 

377 Although this reference model for system services appears to make no distinction, 

378 there are some very important real-world considerations for system services 

379 brought on by the essential differences between realtime and nonrealtime 
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380 systems. One of the best ways to understand these differences is to examine the 

381 performance requirements for system services. 

382 Several metrics are associated with the performance of system services. 

383 Service Request Latency is defined as the interval between (a) context switch from 

384 an application context to the operating system context and (b) the reverse context 

385 switch from the operating system context to the application context for a given 

386 service request. Note that for asynchronous services, the service request may not 

387 have been satisfied within the latency interval. In error situations, return of an 

388 error status or dispatch of the error handler shall be the terminating event for the 

389 measurement. 

390 Service Delivery Latency is the interval between (a) context switch from an appli- 

391 cation context to the operating system context and (b) satisfaction of the service 

392 request. 

393 In some contexts, the most important metric is the wall clock time from the point 

394 that an external, high-priority event occurs to the time the application actually 

395 responds to the event. 

396 However, response time exclusively need not always provide an appropriate 

397 metric. It is also necessary to take into account what must be done within that 

398 time. For example, one system with a one-second response time may be high- 

399 powered enough to handle and coordinate many tasks within that time. Another 

400 system with a faster response time might not be handling the same amount of 

401 processing. 

402 Realtime Metrics 

403 Since a realtime system is defined as one that performs its functions within a 

404 bounded response time, the evaluation of a realtime system has two distinct 

405 requirements. First, it must have the right functions. Second, each function 

406 must be able to guarantee a certain level of performance. 

407 Two major metrics that are concerned with priority interrupts and scheduling are 

408 interrupt latency and context switch time. These are the metrics most commonly 

409 associated with realtime systems. 

410 Interrupt latency is the longest time interval possible for an interrupt to be 

411 received and acknowledged and a process scheduled to service it (see Figure 4-3). 

412 The context switching time is the time required to switch from the task that is 

413 scheduled to service the interrupt. It is determined by the time the operating sys- 

414 tern takes to store the state (context) of the current process so it can continue pro- 

415 cessing its previous task after servicing the interrupt. 
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419 4.2.4 Service Requirements 

420 This subclause identifies those processor-oriented system services required to sup- 

421 port application portability and system interoperability. Subclause 4.2.4.1 

422 describes those system services directly available to an application program via 

423 the System Services API. Other processor-oriented services are described in 

424 4.2.4.4. Subclause 4.2.5 identifies the applicable standards. 

425 This subclause describes the major groups of system services that an application 

426 may require of a platform. Not all of these services require a programming inter- 

427 face; therefore, services are described as either explicit or implicit services. Expli- 

428 cit services are those that can be accessed from an application program (via the 

429 API) and generally are only provided when requested. Implicit services, on the 

430 other hand, are services that the platform provides without a direct request. An 

431 example of an implicit service is the prevention of one program from writing over 

432 the memory of another. An example of an explicit service is a call to a system ser- 

433 vice routine to output the contents of a block of memory to some device. 

434 4.2.4.1 Application Program Interface Services 

435 This subclause describes the major categories of system services available at the 

436 System Services API. These services include: 

437 — Process Management Services 

438 — Task Management Services 

439 — Environment Services 

440 — Node Internal Communication and Synchronization Services 

441 — Generalized Input/Output Services 

442 — File Oriented Services 

443 — Event, Error, and Exception Management Services 

444 — Time Services 

445 — Memory Management Services 

446 — Logical Naming Services 

447 — System Initialization, Reinitialization, and Shutdown Services 

448 4.2.4.1.1 Process Management Services 

449 These services relate to the creation, management, and deletion of processes exe- 

450 cuting within the scope of an operating system. These processes are dis- 

451 tinguished from “tasks” via the following characteristics: 

452 — They have a single thread of execution per address space. 

453 — There is substantial overhead for context switches. 
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454 — Specific attributes are associated only with processes. 

455 In this context, “management” consists of those services that affect the execution 

456 of a process: 

457 — Stop and restart execution of a process (e.g., suspend, resume) 

458 — Modify processor allocation to a process (e.g., priority, timeslice) 

459 — Modify scheduling of the process based on timer (or other) events 

460 — Protect the process from interruption during critical periods 

461 — Create a process and make it ready for execution 

462 — Destroy a process and recover its resources 

463 — Evaluate a reference to a process 

464 — Evaluate a connection to a process, where a connection is a logical commun- 

465 ication path between any two processes 

466 These services schedule or arbitrate the usage of various resources of the OS, par- 

467 ticularly the central processing unit (CPU). The scheduling services must be able D 

468 to queue up requests to use a particular resource. This situation is made more 

469 complicated by the common need to schedule processes to run cyclically at a fixed 

470 period. When a resource becomes idle, the scheduler must select one of the 

471 “requesters” of the resource to grant use of the resource. These services are listed 

472 separately rather than under the services that use scheduling to emphasize that 

473 there should be uniformity and consistency of scheduling across the range of 

474 resources. 

475 Typically, there are at least two types of scheduling occurring in an operating sys- 

476 tern: short-term and long-term. Long-term schedulers determine which possible 

477 requesters at a given time may actually request a resource. The short-term 

478 scheduler selects from among the active “requesters” that currently have need of 

479 the resource and allocates the resource to the selected “requester.” For example, 

480 if the requesters are processes and the resource is the CPU, the long-term 

481 scheduler manages the movement of processes from inactive (waiting in batch 

482 queues or in hibernation) to active (in wait or execute). The short-term scheduler, 

483 on the other hand, would determine which process should execute next on the 

484 CPU. Hybrid services between the two may also be available in the operating sys- 

485 tern. 

486 When a request for a resource is submitted to the operating system (at some local 

487 operating system node), it is not always serviced at that local node. The most 

488 advantageous way to service the request may result in part or all of the work 

489 being performed at a different processor node. Several reasons may cause this to 

490 occur, including load balancing, resource availability, computation speedup, 

491 hardware preference, and software preference. These services may hide from the 

492 application the fact that the functionality was being performed at a different 

493 node. This has the advantage that the code needs to know little about the system 

494 on which it is running. Alternately, the services may allow the user to specify 

495 directly on which logical resource the function should be executed. 
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496 The priority scheduling of resources allows the requester to have associated with 

497 it its importance to use the service. More complex schemes also have a critical- 

498 ness of the request that is used for graceful degradation purposes. The 

499 scheduler(s) will use the priority information to arbitrate resource requests and to 

500 queue requests in the specific order. A priority scheduler may need to support 

501 multilevel queues to support proper execution. 

502 Preemptive schedulers will deallocate a resource from a requester when certain 

503 events occur. Usually this is when a requester of a higher priority or importance 

504 requests the resource or a specified time limit for the resource has expired. 

505 4.2.4.1.2 Task Management Services 

506 These services relate to the creation, management, and deletion of tasks execut- 

507 ing within the scope of an operating system. These tasks are distinguished from 

508 “processes” via the following characteristics: 

509 — There may be multiple threads of execution per address space. 

510 — There is low overhead for context switches between threads located in the 

511 same address space. 

512 In this context, “management” consists of those services that affect the execution 

513 of a task: 

514 — Stop and restart execution of a task (e.g., suspend, resume). 

515 — Modify processor allocation to a task (e.g., priority, timeslice). 

516 — Modify scheduling of the task based on timer (or other) events. 

517 — Protect the task from interruption during critical periods. 

518 — Create a task and make it ready for execution. 

519 — Destroy a task. 

520 — Evaluate a reference to a task. 

521 — Evaluate a connection to a task, where a connection is a logical communica- 

522 tion path between any two tasks. 

523 4.2.4.1.3 Environment Services 

524 These services provide an application access to a variety of information relating to 

525 the operating system environment in which the application is executing. The 

526 specific characteristics are: 

527 — Process-specific attributes (process identification, priority, stack size, 

528 scheduling attributes, status, memory allocation). 

529 — Task-specific attributes (task identification, priority, scheduling attributes, 

530 status, memory allocation). 

531 — Processor-specific attributes (node identification, electronic nameplate 

532 information). 
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533 — User-specific attributes (user identification and terminal ID, user interac- 

534 tion profile). 

535 — Environment variables (command-line arguments, menu selections). 

536 — Current time and date 

537 4.2.4.1.4 Node Internal Communication and Synchronization Services 

538 One or more applications and application subcomponents may run on a processor D 

539 within an application platform simultaneously. The applications run as indepen- D 

540 dent software entities and communicate among themselves via a variety of D 

541 mechanisms provided or managed by the system services (see Figure 3-2). An D 

542 important class of system services relates to the coordination and synchronization D 

543 of these software entities. In traditional systems, entities execute on a single D 

544 hardware processor. However, it is becoming common to have multiple processors D 

545 and networked processors that place more requirements on the system services to D 

546 provide coordination and synchronization among the many truly concurrent D 

547 software entities. D 

548 When a platform has several software entities executing concurrently, the appli- D 

549 cations need system services so that the entities can be coordinated and synchron- D 

550 ized with each other. With respect to applications written using concurrency, D 

551 there are two levels of concurrency that are usually seen by the application D 

552 developer. The first level of concurrency, task level concurrency, is seen when the D 

553 application is split into multiple subcomponents (tasks) that share access to the D 

554 data and subprograms of the application. Concurrency services at this level con- d 

555 cern the relative priorities and scheduling of tasks within a single application pro- D 

556 gram and their communication with each other. At the second level of con- D 

557 currency, application level concurrency, a unit is a single application including all D 

558 its subcomponents. Concurrency services at this level concern the relative impor- D 

559 tance of the individual applications competing for and sharing system resources. D 

560 These services are used to communicate among processes, among tasks, and 

561 among processes and tasks residing on the same node. The methods outlined do 

562 not include the network specific services described in 4.3, but are limited to 

563 methods open to entities executing within the scope of a single operating system. 

564 Both synchronous and asynchronous services are defined. The specific services 

565 are: 

566 — Create, delete, open, close, read, and write shared memory. 

567 — Create, delete, read, and write event flags. 

568 — Create, delete, set, and wait on semaphores. 

569 — Create/send and receive signals. 

570 — Create, delete, open, close, send to, get from, and control message queues. 

571 — Create, delete, send, and receive streams. 
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572 4.2.4.1.5 Generalized Input/Output Services 

573 These services are used by an application to perform generalized device I/O opera- 

574 tions. These operations include synchronous and asynchronous operations for 

575 device and class specific functions. Specifically, these form the services needed to 

576 implement or include logical device drivers in a system. These services are device 

577 initialization, device attachment, asynchronous operation, and error notification. 

578 In addition, they include those services that are used to directly access specific 

579 device capabilities, particularly those services often referred to as “raw I/O.” 

580 4.2.4.1.6 File Oriented Services 

581 Mass storage in the form of hierarchy of directories, subdirectories and files will 

582 be available to an application executing within the application platform. The fol- 

583 lowing paragraphs describe the services available for creating, accessing, manag- 

584 ing, and deleting these entities with mass storage. Both synchronous and asyn- 

585 chronous services are defined. 

586 Naming and Directory Services 

587 These services allow the access of files and directories through logical names 

588 rather than the actual hardware device naming conventions. The services allow 

589 sharing of files at various levels. For example, the services may not allow any 

590 shared naming of files and directories between systems, or they may allow shared 

591 files by explicit naming, or they may allow shared files by implicit naming. The 

592 directory services present a view or views of the directory structure to the applica- 

593 tion or target system operator. 

594 File Modification Primitives 

595 Primitive services for files and directories are: 

596 — Read a portion of the file. 

597 — Write to a portion of the file. 

598 — Open access to a file. 

599 — Create a new file. 

600 — Close access to a file. 

60 1 — Delete a file. 

602 — Copy a file. 

603 — Merge two or more files. 

604 — Append one file to another. 

605 — Split one file into two or more files. 

606 — Support read and write locks at both the record and file levels. 

607 These services may be very complex. For example, the access to read or write 

608 may be direct (by record number), sequential (one record at a time), or indexed (by 
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609 a key). The services must also support a variety of file structures, including 

610 linked, segmented, contiguous, serial, and directory. 

611 File Support Services 

612 Additional services support the physical devices on which the files and directory 

613 reside. These services include the dismounting/mounting of medium, the format- 

614 ting of medium, and the partitioning of media. 

615 Realtime Files 

616 Realtime systems often need special files to ensure fast, bounded, and consistent 

617 performance in time critical situations. The need for a bounded response time for 

618 a given I/O function drives the design of these files and services. One service 

619 preallocates the complete disk space needed for a file at creation time, while 

620 another guarantees that records within files are aligned in an optimal way (such 

621 as along word boundaries). Services support the access of records within the file 

622 in ways that make response time constant or bounded, including by direct access. 

623 4.2.4.1.7 Event, Error, and Exception Management Services 

624 These services provide a common facility for the generation and communication of 

625 asynchronous events among the system and application programs. A major use of 

626 the event services is to report error conditions, but they are also used by device 

627 drivers and the platform to provide an indication of some condition to the applica- 

628 tion programs. These services are: 

629 — Event and error receipt. 

630 — Event and error distribution. 

631 — Event and error management, including user-selectable error processing 

632 alternatives (filtering, retry, ignore, accumulate occurrences). 

633 — Event logging. 

634 — Enable/disable and mask/unmask interrupts. 

635 4.2.4.1.8 Time Services 

636 Timers may be a static or dynamic resource on the system, necessitating a variety 

637 of allocation and management strategies. These services are used by applications 

638 to perform a variety of services based on absolute and relative time. These ser- 

639 vices are: 

640 — Create a timer. 

641 — Delete a timer. 

642 — Initiate the measurement of an arbitrary specified time duration. 

643 — Receive an indication when the specified duration has elapsed. 

644 — Read the current value of a timer. 
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645 — Initialize a timer with a value and count direction (i.e., increment or decre- 

646 ment). 

647 — Trigger a timer to begin incrementing or decrementing. 

648 — Associate with a timer some action to be taken when the specified duration 

649 has elapsed. 

650 4.2.4.1.9 Memory Management Services 

651 These services are used by application processes and tasks to request additional 

652 memory and return it to the processor for reuse. They cover the services required 

653 to fulfill the needs of both virtual and fixed memory. Specifically, there is a ser- 

654 vice for locking pages in real memory to support the needs of virtual memory sys- 

655 terns. 

656 4.2.4.1.10 Logical Naming Services 

657 These services allow the usage of system resources through logical names rather 

658 than the actual hardware device naming conventions. Furthermore, they allow 

659 the resources of other processor nodes to be accessed via a logical name so that no 

660 knowledge of the resource’s location is needed and the resource’s location may 

661 change over time. Logical names are also used by security services to hide 

662 resources from unauthorized processes by only letting authorized processes know 

663 the logical name that is needed to use the physical resource. 

664 The logical name to physical name relationship can be one to many, many to one, 

665 or many to many. Many times, one physical resource may have multiple logical 

666 names as well as one logical name representing a “bank” of available physical 

667 resources. These services must provide the proper resolution of names, logical 

668 and physical, in all of these cases. 

669 4.2.4.1.11 System Initialization, Reinitialization, and Shutdown Services 

670 System initialization consists of services for a complete restarting of the software, 

671 starting up the attached hardware subsystems devices, doing subsystem and sys- 

672 tern self tests, and completely initializing the database. 

673 System reinitialization consists of services for restarting the software while using 

674 the existing database information. The software may have to be reloaded and the 

675 database may have been reestablished by a system recovery. Attached hardware 

676 subsystems may also need to be reinitialized. 

677 Reinitialization also includes a function to restart applications redistributed to 

678 other processors after a processor module failure. Within a processor, there is a 

679 service to initialize applications in a system with the existing software, but with 

680 the database reinitialized. Also within a processor, there is a service to restart 

681 the applications in a system with the existing software and database retained. 

682 Shutdown services are those required to perform planned orderly shutdown at the 

683 local and remote levels for each and all processor(s) throughout a system. These 

684 services support both crisis and non-crisis situations that call for system 
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685 shutdown. They make sure that the persistent store is in a consistent state, see 

686 to the clean termination of all processes, programs, devices, etc., and take care of 

687 user notification. They also provide for the running of system diagnostics. 

688 4.2.4.2 External Environment Interface Services 

689 Data Interchange External Environment Interface Services are required by the 

690 System Services. Of particular interest are the formats, locations, and procedures 

691 for using system administration files, such as password files, system startup files, 

692 and configuration files. 

693 4.2.4.3 Interapplication Software Entity Services 

694 This could include support for generalized network/multisession services, such as 

695 message handling between system components, global object definition 

696 specification, and intermediate language definition. 

697 4.2.4.4 Resource Management Services 

698 These services provide general management functions across the entire platform. 

699 They consist primarily of system administration-oriented functions (i.e., manage- 

700 ment of system interfaces within the scope of the administrator, such as setting 

701 up defaults and limits.) 

702 4.2.4.4.1 System Operator Services 

703 The system operator needs to access and control the system services in order to 

704 allow the platform to perform properly. If a system has an operator, the major 

705 functions that need to be supported are system control, reconfiguration, and 

706 status reporting. Currently, these services are usually made available to an 

707 operator through a command language interpreter, which is an application pro- 

708 gram that accesses these system services. 

709 Note that the Windowing Services provide the building blocks (menu utilities, 

710 command parsers, etc.) for building the user interface while the System Operator 

711 Services make available operating system status and control functions to 

712 appropriate application programs with the proper security level. 

713 These services support general conventions and specifications for interaction 

714 between system components. 

715 4.2.4.4.2 System Administration 

716 These services and procedures are those required to assure management and allo- 

717 cation of system services to system users, both local and remote. They consist pri- 

718 marily of those services required to establish authorized users of the system, with 

719 associated allocation of processor resources, including memory, processor time, 

720 priority, and mass storage space. These services are both static (as in the estab- 

721 lishment of a new user identification) and dynamic (as in login/logout). 
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722 4.2.5 Standards, Specifications, and Gaps 


723 Table 4-2 - System Services Standards Activities 

724 _ 


725 

Service 

Specification 

Subclause 

D 

726 

Process Management 

ISO/IEC 9945-1 

4.2.5.1.1.1 

D 

727 

Task Management 

ISO/IEC 9945-1 

4.2.5.1.1.1 

D 

728 

Environment Services 

ISO/IEC 9945-1 

4.2.5.1.1.1 

D 

729 

Node Internal Comm/Synch 

ISO/IEC 9945-1 

4.2.5.1.1.1 

D 

730 

Generalized I/O 

ISO/IEC 9945-1 

4.2.5.1.1.1 

D 

731 


OSF AES - OSC 

4.2.5.3.1 

D 

732 


SVID 

4.2.5.3.1 

D 

733 

File Oriented Services 

ISO/IEC 9945-1 

4.2.5.1.1.1 

D 

734 

Event, Error, and Exception 

ISO/IEC 9945-1 

4.2.5.1.1.1 

D 

735 


OSF AES - OSC 

4.2.5.3.1 

D 

736 


SVID 

4.2.5.3.1 

D 

737 

Time Services 

ISO/IEC 9945-1 

4.2.5.1.1.1 

D 

738 

Memory Management 

ISO/IEC 9945-1 

4.2.5.1.1.1 

D 

739 

Logical Naming 

ISO/IEC 9945-1 

4.2.5.1.1.1 

D 

740 

System Init/Reinit/Shutdown 

ISO/IEC 9945-1 

4.2.5.1.1.1 

D 

741 


OSF AES - OSC 

4.2.5.3.1 

D 

742 

743 


SVID 

4.2.5.3.1 

D 


744 4.2.5.1 Current Standards in the POSIX OSE 

745 4.2.5.1.1 International Standards 

746 4.2.5.1.1.1 Portable Operating System Interface (POSIX) Part 1 

747 ISO/IEC 9945-1 (IEEE Std 1003.1) is the first in a set of planned international 

748 POSIX standards. It defines services and characteristics that need to be in the 

749 platform for portable applications, as do some of the other planned standards. 

750 Another type of POSIX-related standard is bindings for those services to specific 

751 languages. The third type deals with concepts that cross between various group- 

752 ings of services, such as security and distributed processing. 

753 Objectives 

754 The purpose of the ISO/IEC 9945-1 standard is to define a standard operating sys- 

755 tern interface based on the UNIX Operating System documentation to support 

756 application portability at the source level. The document is intended for systems 
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757 implementors and applications software developers. 

758 In addition to ISO/IEC 9945-1, ISO is planning to publish ISO/IEC 9945-3 Confor- 

759 mance Test Procedures (which will be identical to IEEE 1003.3). This standard 

760 will cover conformance testing procedures for 9945-1. 

761 Functionality 

762 Table 4-3 outlines the contents of the current document. This document is identi- 

763 cal in its ISO/IEC form (ISO/IEC 9945-1) and the US national standard form (IEEE 

764 Std 1003.1). Revisions are currently in progress to deal with: 

765 — A language-independent services specification 

766 — A unified data interchange format 

767 — Service interfaces for control of character cell terminals 

768 — Miscellaneous functions identified in comments on the current standard. 

769 

770 

771 

772 

773 

774 

775 

776 

777 

778 

779 

780 

781 

782 

783 

784 

785 

786 

787 

788 

789 

790 
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Table 4-3 - Functionality of POSIX. 1 Standard 

File system organization, and file naming conventions 

System configuration and file system configuration characteristics 

Error messages and reporting mechanism ( errno ) 

Application environment information ( environ) 

Process creation, management, and termination: exec(), fork(), wait() 

Process environment: user ID, process ID, Group ID 
Exception conditions and handling (signals) 

Timer operations 

File and Directory operations: FIFO files, pipes, status, open/close, read/write 
File protection mechanisms 
Record and file locking mechanism 

Device specific functions: Terminal controls: Processing modes: echo, baud rate, 
modem termination 

C language specific routines: setlocale (), nonlocal jumps 

User and Group database information (excluding password information) 

Data interchange formats (USTAR and CPIO) 

Also included is a rationale appendix that provides insight on the selection of various 
functions and features, including some guidance to developers to understand what 
types of variations may exist and how that can impact portability. 
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791 Options and Variations 

792 The ISO/IEC 9945-1 standard draws heavily upon major implementations of the 

793 UNIX Operating System, including System V and the Berkeley versions. Where a 

794 specific behavior was clearly needed (e.g., signals), only a single behavior was per- 

795 mitted. However, there are points where functions were considered optional and 

796 others where two different behaviors were considered acceptable. However, in 

797 many cases, a solid technical argument favoring one approach over the other was 

798 not established. In this case, two behaviors (usually System V and BSD) are 

799 defined as being permitted. This is of benefit in writing portable applications, 

800 since those that can tolerate both behaviors will run on a wider range of systems. 

801 It is also a slight disadvantage in writing such applications, since it can mean 

802 handling a wider range of implementations. 

803 NOTE: In a related U.S. national standard, the United States Government Department of Com- 

804 merce National Institute of Standards and Technology has adopted the ISO/IEC 9945-1 standard as a 

805 Federal Information Processing Standard (FIPS 151-1) for use in computer systems procurement. 

806 FIPS 151-1 requires options and characteristics that have not been required by ISO/IEC 9945-1, 

807 requiring implementations to function in a specific way in many of these cases. While buyers may 

808 want to make such requirements, the impact should be understood. Applications written for FIPS 

809 systems may only run on FIPS systems, whereas applications written for full ISO/IEC 9945-1 imple- 

810 mentations will run on both FIPS systems and POSIX conforming systems that are not FIPS conform- 

811 ing. FIPS systems will run applications written either way. 

812 FIPS 151-1 requires all three POSIX.l options. In addition, it eliminates several additional possible 

813 behaviors, thus narrowing the variation between conforming implementations. 

814 4.2.5.1.2 Regional Standards 

815 None. 

816 4.2.5.1.3 National Standards 

817 None. 

818 4.2.5.2 Emerging Standards in the POSIX OSE 

819 4.2.5.2.1 International Standards 

820 None. 

821 4.2.5.2.2 Regional Standards 

822 None. 

823 4.2.5.2.3 National Standards 

824 The IEEE P1003.4 Group is defining realtime extensions to ISO/IEC 9945-1. Draft 

825 9 of the realtime POSIX extensions proposes standardized interfaces to the follow- 

826 ing functions: 
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827 — Response to asynchronous events 

828 — Priority interrupts and scheduling 

829 — Preemptive scheduling 

830 — Memory locking 

831 — High-performance file system (contiguous or other) 

832 — Realtime timers (with nanosecond resolution times) 

833 — Shared memory 

834 — Semaphores 

835 — Interprocess communications (message passing) 

836 — Asynchronous event notification 

837 — Synchronous input and output. 

838 The P1003.4 group is also specifying an interface to threads (P1003.4a). 

839 4.2.5.3 Gaps in Available Standards 

840 While ISO/IEC 9945-1 and P1003.4 both represent very important work, they do 

841 not yet address all of the services indicated in 4.2.4. Areas of particular shortfall 

842 include Event, Error, and Exception Management Services, some Generalized I/O 

843 Services (particularly concerning services for device drivers), and System Initiali- 

844 zation, Reinitialization, and Shutdown Services. In addition, Security (see 5.2) 

845 and Reliability, Adaptability, and Maintainability (Fault Tolerance; see 5.4) ser- 

846 vices are not reflected in these two base standards, and some capabilities are 

847 explicitly considered to be implementation defined. For some of the services dis- 

848 cussed here, adequate consideration is not given to the implications of multipro- 

849 cessor and distributed implementations of the services and interface provided. 

850 Finally, since these are intended to be base standards (or, in the case of P1003.4, 

851 an extension to a base standard), profiles are needed in order to select appropriate 

852 features and provide appropriate combinations with other related capabilities. 


853 4.2.5.3.1 Public Specifications d 

854 The following are public specifications that define interfaces to services for which D 

855 no formal standards are currently available. D 

856 OSF/1 D 

857 The Open Software Foundation (OSF) “Application Environment Specification d 

858 (AES)—Operating System Component” (OSC). D 

859 Service Gaps Addressed: d 

860 — Generalized I/O D 

861 — Event, Error, and Exception D 
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862 

— System Init/Reinit/Shutdown 

D 

863 

SVID 

D 

864 

The AT&T System V Interface Definition (SVID), Issue 3. 

D 

865 

Service Gaps Addressed: 

D 

866 

— Generalized I/O 

D 

867 

— Event, Error, and Exception 

D 

868 

— System Init/Reinit/Shutdown 

D 


869 4.2.5.3.2 Unsatisfied Service Requirements 

870 There are two significant areas of the services described above for which no stan- 

871 dards currently exist. One is the considerations implied by the use of multipro- 

872 cessors to implement some or all of the services described herein. The other area 

873 is that of interfaces to logical device drivers. 

874 4.2.5.3.3 Standards/Specifications Outside the POSIX OSE 

875 4.2.6 OSE Cross-Category Services 

876 4.2.6.1 Capability and Security Services 

877 These services support the ability of the system to control usage such that system 

878 integrity is protected from inadvertent or malicious misuse. These protection ser- 

879 vices provide a mechanism for the enforcement of the policies governing resource 

880 usage. Note that many of the security services are implicit services; i.e., they are 

881 provided without an explicit request to the operating system. There are two dis- 

882 tinct classes of system access with which operating system services must be con- 

883 cerned: physical access and logical access. 

884 Security services at the physical level are used to protect against security 

885 compromise, given unauthorized personnel may have physical access to system 

886 hardware. Typically, the physical access is to a terminal and/or terminal/display 

887 cables; however, physical access may also include network cables, central process- 

888 ing units, disk drives, or tape drives. Prevention of physical access by unauthor- 

889 ized personnel may require different operating system services under different 

890 circumstances. 

891 Logical access is the ability to interact with the operating system via a 

892 terminal/display. Security services at the logical level can be implemented 

893 through passwords and watchdog timers. 

894 Capability services attach operation lists that limit a process’s ability to act on 

895 resource objects. This is to ensure the resources are not misused. Access to 

896 resources can be protected by services using capability lists as well as access lists, 

897 lock/key mechanisms, global tables, or through dynamic protection structure ser- 

898 vices. 
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899 Prevention of Unauthorized Access 

900 The system may need to be guarded from attempted access by unauthorized per- 

901 sonnel. The point of access to the operating system that is typically of concern is 

902 through the API. Given the mode of operation (system high, multilevel, open) at 

903 which the system is operating, these services differ and have differing implica- 

904 tions on other system services (such as reliability and naming) and system perfor- 

905 mance. 

906 Prevention of Data Compromise 

907 These services prevent access of data by users not authorized to the data. These 

908 services may be implemented using access lists on files (and directories) and/or 

909 encryption of data or in other ways. 

910 Prevention of Service Denial 

911 These services ensure that a service request will be met by the operating system 

912 in a reasonable time if the requester is authorized to use the service. These ser- 

913 vices ensure that a bandit user or process cannot cause system malfunction by 

914 monopolizing system services or resources. 

915 Security Administration 

916 This category involves services to allow the management of the security system, 

917 including the administration of permissions to personnel, data, and services as 

918 well as capability lists. In addition, it permits the administration access mechan- 

919 isms (most often passwords and capability lists) and services that allow the sys- 

920 tern to switch modes of operation. The services will likely be accessed by the tar- 

921 get system operator with security responsibilities through the target system 

922 operator services. 

923 4.2.6.2 Fault Management 

924 Many of the fault management capabilities described in 5.4 are normally the 

925 responsibility of the operating system and fall under the sorts of services 

926 described in this clause. 


927 4.2.7 Related Standards 


928 The following emerging standards are related to the services covered in this d 

929 clause, in as much as they address at some level services either explicitly listed in 

930 or implied by the services found in 4.2.4: 


931 

932 

933 

934 


P1003.6 Security Interface for POSIX. 

P1003.12 Protocol Independent Interfaces (for networks). 

P1238 OSI Application Program Interfaces (initial effort is to provide at 

least sufficient facilities for the support of FTAM API 
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935 specifications). 

936 4.2.8 Open Issues 

937 [PO: PCTE and CAIS-A have been moved here largely because it is not clear what to 

938 do with them. They are not adequately accommodated by this model. They are 

939 both hybrids of operating system and database management system capabilities 

940 that seem to belong either everywhere or nowhere. They could both well be used in 

941 conjunction with a P1003.1 implementation, but they could also be implemented 

942 on other base operating systems, or implementations could even expand their capa- 

943 bilities to provide full operating systems. P1003.0 must decide what to do with 

944 them.] 

945 PCTE 

946 An effort by the European Computer Manufacturers Association (ECMA) has 

947 resulted in the definition by Technical Committee 33 of the Basis for the Portable 

948 Common Tools Environment (PCTE). This is now an ECMA standard and is 

949 referred to as Standard ECMA-149. 

950 CAIS-A 

951 MIL-STD-1838A (CAIS-A) was developed by the US Department of Defense to pro- 

952 vide a common foundation for Ada Programming Support Environments. Similar 

953 in nature to PCTE (see above), it too covers many of the system services covered by 

954 4.2.4. In addition, it provides data management services such as those discussed 

955 in 4.4 and data interchange services (specifically, a Common External Form) simi- 

956 lar to those discussed in 4.5. 


957 X/Open 

958 [PO: The following text on XPG was given to me at the last meeting. However, I 

959 cannot tell from the text whether XPG is more like this guide or more like P1003.1. 

960 If it is the former, it does not belong here. If it is the latter, then this text should be 

961 moved into 4.2.5.3.1.2.] 

962 X/Open is a consortium formed to create interface definitions and guidelines that 

963 will provide portability and interoperability to its members’ products. Its primary 

964 output is the X/Open Portability Guide. The functional content of this guide is 

965 heavily based on the AT&T SVID. The current version is XPG3. 

966 [PO: Documentation of open issue: what are we going to do with FIPS? For this 

967 section, the decision was made in Chicago to stick FIPS 151-1 in the section on 

968 9945-1, but this proved quite awkward: it couldn’t be placed in the regular text 

969 because it didn’t pertain directly to 9945-1 (i.e., it was inappropriate to discuss it 

970 in the text that was to be devoted to “international standards”), so it ended up in 

971 an informative note. I don’t find this a satisfactory answer. I think that it prop- 

972 erly belongs under Government / Legal Standards; the “gap” it fulfills is one of 
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973 profiling. 

974 Documentation of new open issue: We are beginning to “use our heads,” as indi- 

975 cated by the discussions we had on this section in Chicago. It is essential that we 

976 capture the rationale for our decisions, particularly for our inclusions and exclu- 

977 sions. I have tried to do that here to some extent, but what is our overall plan for 

978 making sure that our rationales are not lost?] 
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979 4.3 Network Services 

980 Responsibility: Charles Severance D 

981 HLJ: This is a complete clause replacement in Draft 13. It is not further cliff- D 

982 marked. D 

983 4.3.1 Overview and Rationale 

984 This clause describes the network services component of the application platform. 

985 It also describes the services provided to application programs and users, and it 

986 describes current and emerging standards that are standardizing these services. 

987 Applications gain direct access to network services via the POSIX API. The net- 

988 work is just another system resource (albeit an important one) allocated among 

989 the competing processes. 

990 4.3.2 Scope 

991 Network services include those capabilities required to allow application pro- 

992 grams to execute on platforms that may be connected via a network. They cover 

993 the areas of file transfer, namespace and directory services, services in support of 

994 distributed environments such as remote procedure call, distributed time 

995 management, transparent file access, and data representation services. The 

996 application programs using these services should be able to access them via a 

997 high-level, context-insensitive or low-level, context-dependent interface. 

998 In the open systems and distributed systems environments, interoperability is of 

999 equal or greater importance than portability. The interfaces provided by the net- 

1000 work services must be network protocol independent and provide for this level of 

1001 interoperability. The network protocols defined for both Open Systems Intercon- 

1002 nect (OSI) and Internet Protocol Suite (IPS) for TCP/IP should provide the basis for 

1003 the open networking interfaces; however, these interfaces should not preclude the 

1004 use of some subsequent networking protocol in the future. 

1005 Rationale: It is important for an open system to interoperate with more systems 

1006 than just other open systems. Many open systems users will have requirements 

1007 to interoperate with non-ISO networks for the near future. 

1008 4.3.3 POSIX OSE Network Services Reference Model 

1009 This subclause identifies the entities and interfaces specific to the construction of 

1010 an POSIX Network Environment. This environment is consistent with and 

1011 extends the environment of Section 3. 

1012 As illustrated in Figure 4-4, the components of a network architecture that 

1013 require standardization are divided into two groups called external environment 

1014 interfaces (EEI) and application program interfaces (API). 
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1015 


Network Services EEI: 

— Data Transport Services 

— Routing and Relay Services 

— Incoming Connection Services 

— Network Management and Security Commands 

— General Network User Commands 


1016 _ 

1017 Figure 4-4 - POSIX Networking Reference Model 

1018 There may be some correspondence between services offered to the application 

1019 across the API and the interfaces available at the EEI. It is quite possible for an 

1020 API service to have no corresponding effect at the EEI. A good example of this is 

1021 an interapplication communication service provided by the Network API between 

1022 two applications on the same application platform. There may also be services 

1023 available at the EEI provided by the Application Platform that are not available at 

1024 the API such as remote login services. 

1025 4.3.3.1 Network Application Program Interface (API) Services 

1026 The API is concerned with the interfaces and associated standards that apply to 

1027 the interface between the application and the application platform. 

1028 The services available at the API are: 

1029 — Directory Services 

1030 — Application to Platform Services 

1031 — Application to Application Communication Services 

1032 — Data Representation Services Services 

1033 — Distributed System Services 

1034 — Network Management and Security Services 



Network Services API: 

— Directory Services 

— Application-to-Platform Services 

— Application-to-Application Comm Services 

Remote Procedure Call (RPC) API 
Simple Network API 
Detailed Network API 

— Data Representation Services 

— Distributed System Services 

— Network Management and Security Services 
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1035 Directory Services are those services associated with identifying and naming net- 

1036 work elements. 

1037 Application to Platform Services provide an application with a very high level 

1038 interface to networking capabilities. This interface provides applications with 

1039 capabilities such as “mail this file to this address” or “transfer user xxx file from 

1040 host yyy to the local host.” These services do not require the application to be 

1041 aware of any of the low level network details. 

1042 Application to Application Services are the services provided by the Application 

1043 Platform that allow an application to communicate with another application to 

1044 exchange information. These interfaces support applications that range from hav- 

1045 ing extremely simple networking requirements to the most complicated applica- 

1046 tions that must make full use of every possible network capability. 

1047 Data Representation Services provide the application with network oriented data 

1048 representation services to insure the application can interchange information 

1049 with other entities in the proper format. 

1050 Distributed system services provide the application with the ability to make use 

1051 of multiple physical computer systems resources. 

1052 Network management and security services allow the application to control and 

1053 configure the network resources. 

1054 4.3.3.2 External Environment Interface Elements 

1055 4.3.3.2.1 User Interface EEI Elements 

1056 The User interface EEI elements include the commands that users can use to per- 

1057 form network functions such as: 

1058 — File transfer 

1059 — Electronic Mail 

1060 — Remote printing 

1061 These commands are considered to be beyond the scope of this clause and will be 

1062 covered in 4 . 9 . 

1063 The User interface EEI elements that will be covered in this section are the com- 

1064 mands that are used to perform network management and security functions. 

1065 4.3.3.2.2 Communication EEI Elements 

1066 The primary focus of the network EEI is the network protocols and supporting for- 

1067 mats for network communication. 

1068 The entities in the external environment may be other application platforms or 

1069 user interface equipment connected to the network using the open networking 

1070 protocols. The standards at the EEI will be in several areas including: 
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1071 — Physical connections 

1072 — Network protocols and formats 

1073 — Distributed systems services 

1074 The standards at the EEI will impact system interoperability but also may have 

1075 an effect on application portability because certain applications may require par- 

1076 ticular types of network access to operate. 

1077 4.3.3.3 Implementation Aspects 

1078 The POSIX OSE Network reference model focuses on the requirements of applica- 

1079 tion portability and system interoperability. As such, the model does not 

1080 represent how systems are actually put together. 

1081 In the network area, there is much effort dedicated to the design of network stan- 

1082 dards to allow network components to be re-usable. This subclause shows how 

1083 some of these network standards are related within the POSIX Network Reference 

1084 Model. 

1085 Other network models are also related to the POSIX OSE Network Reference 

1086 models. None of these other models are in conflict with the POSIX OSE Network 

1087 Reference model. These models show much more detail in the area of how dif- 

1088 ferent standards work together. 

1089 4.3.3.3.1 Relationship Between the OSI Reference Model and the POSIX 

1090 OSE Network Reference Model 

1091 Figure 4-5 shows the OSI seven layer model for networking as standardized by 

1092 ISO [ref]. 

1093 There are many aspects of network architecture that are specified by the OSI Net- 

1094 work Model model: 

1095 — The number of layers in the model and the roles for each layer. 

1096 — An indication of which layers are logically end to end and which layers are 

1097 simply to the next physical network node. 

1098 — The protocols between the layers and the protocols between the peers 

1099 within the same layer. This has an impact on the actual format of the 

1100 information transferred between nodes at the physical layer. 

1101 In addition, this model specifies how networks of computer systems can be assem- 

1102 bled using the routing capabilities of intermediate nodes. 

1103 The POSIX OSE Network Reference Model has a much more limited scope than the 

1104 OSI network model. The POSIX OSE reference model only looks at two interfaces 

1105 to an application platform: the interface between application software and the 

1106 application platform (API) and the interface between the application Platform and 

1107 the External Environment (EEI). At both the API and EEI, the POSIX OSE net- 

1108 work model describes the services that are provided to the application or external 

1109 environment at the interface. 
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1110 



1111 _ 

1112 Figure 4-5 - ISO Networking Reference Model 

m3 Figure 4-6 shows how the two models could be related for one of the POSIX OSE 
iii 4 Network Reference Model Application Programming Interfaces and three of the 
ms External Environment Interfaces. The POSIX OSE reference model focuses on a 

1116 single application platform rather than a whole network. The POSIX Network API 

1117 includes the API provided to interface to the application layer of the OSI model. 

ms Because the OSI portions of the Application Platform External Environment Inter- 

1119 face depend on the format, protocol, and services of what is produced at the physi- 

1120 cal level of the OSI reference model, the EEI technically depends on all seven 

1121 layers the OSI model plus the services added on top of the application layer such 

1122 as platform provided services or network management services. 

1123 This guide will not call out all of the standards that specify the protocols, formats, 

1124 and options for all seven layers of the ISO network standards. Instead, this guide 

1125 will focus on the services provided at the EEI using all of those formats and proto- 

1126 cols. 

1127 Figure 4-7 shows an API interface to only layer seven of the OSI Network inter- 

1128 face, which is intended to be the primary API for accessing network services. It is 

1129 possible to define APIs that interact directly with any of the seven layers. There 

1130 are a number of pragmatic reasons to provide APIs that access layers below layer 

1131 7 . The cost of using one of these lower layer APIs is that the applications may 

1132 sacrifice portability and/or interoperability. 

1133 It is important to note that while these APIs are represented as a part of a layered 

1134 network architecture, from the point of view of the application interacting with 

1135 the application platform, this layering is not critical to the use of the services. 

1136 From the application perspective, there are simply three different types of 
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1137 



1138 _ 

1139 Figure 4-6 - Relationship of ISO and POSIX OSE Network Reference Models 


1140 network services, each with a different set of capabilities and requirements. 

1141 Whether or not there is any actual layering or code common to the three services 

1142 is implementation dependent. 

1143 4.3.3.3.2 POSIX Network Standards Efforts 

1144 The current POSIX approach to networking focuses on producing Application Pro- 

1145 gram Interface (API) specifications. Most of the network connectivity 

1146 specifications at the External Environment Interface are well covered on other 
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1147 



1148 _ 

1149 Figure 4-7 - Multiple POSIX OSE APIs to Different OSI Layers 

1150 standardization areas such as ISO (OSI networking) and the RFC process (TCP/IP). 

1151 One important aspect of the POSIX networking approach is that it is not focusing 

1152 solely on producing standard APIs for OSI Network services. The POSIX Simple 
H53 Network Interface (P 1003.12 SNI) is explicitly designed so to be implemented 
1154 transparently on a wide variety of networks. At the current time the possible list 
H55 includes: 

1156 — OSI Application Layer 

1157 — OSI Transport Layer 

1158 — TCP/IP 

1159 — Other networks including proprietary networks 

1160 The current POSIX API standardization efforts include: 

1161 — P 1003.12 — Simple Network API 

H62 — P 1003.12 — Detailed Network API 

1163 — P 1003.17 — Directory Services API 
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1164 — P 1238.0 — OSI Application Layer API (ASCE) 

1165 — P 1238.1 — OSI Application Layer API (FTAM) 

1166 _ 



1167 _ 

1168 Figure 4-8 - Basic Network Services Model 


H69 Figure 4-8 shows how the basic network services can be related. The Simple Net- 

1170 work Services API is designed so that a Simple Network Services Implementation 

1171 can be done using the services available using the Detailed Network Interface 

1172 API. An application can use the Detailed Network Interface to access multiple 

1173 network transports but there may be differences between networks visible at the 

1174 API. Applications that need to be portable across different types of network tran- 

1175 sports should be written using the Simple Networking Interface. 

1176 It is important to note that while the SNI API and DNI API standards have been 

1177 designed so that the SNI Services can make use of the DNI API to access transport 

1178 services, it is not a requirement that every implementation of SNI Services be 

1179 written using the DNI API to access transport services. From the point of view of 
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1180 the application program, it is only important that the application platform pro- 

1181 vide an API for both the SNI and DNI services. This interface between the SNI 

H82 Services and the Transport Services is an example of a Systems Integration Inter- 

1183 face as described in 3 . 6 . 

1184 Another example of Systems Integration Interface that is the subject of discussion 

1185 in the POSIX Network area is the interface between the OSI Network Services and 

1186 the transport services. This may or not be required to be the DNI API. This is an 

1187 example of an interface that should have no impact on user application portability 

1188 but may have great impact on the ability to procure the different types of network 

1189 services from different vendors. 

H90 The area of Directory Services (P 1003 . 17 ) is also specified so to be able to make 

1191 use of different types of Directory Services including: 

1192 — X .500 Directory Services 

1193 — TCP/IP Directory Services 

1194 — POSIX P 1003.7 System Administration and Management Services 

H95 Figure 4-9 shows how the Directory Services are related to the other network ser- 

1196 vices. All of the APIs and SIIs from the previous figure have been eliminated to 

1197 reduce the number of interfaces shown on the figure. 

1198 4.3.4 Service Requirements 

1199 The service requirements for the network component of an open system are very 

1200 wide ranging. Many of the other components of the application platform make 

1201 implicit or explicit use of network services. 

1202 Much standardization effort has gone into the aspects of networking that are 

1203 available at the external environment interface. Effective networking standards 

1204 at the external interface are fundamental to providing system interoperability. 

1205 The service requirements for both the API and EEI are described in this section. 

1206 CRS: Comment to mock ballot reviewers: This section is supposed to state the ser- 

1207 vices required by an application at the API and the requirements that users and 

1208 networks place on the external interface of the computer system. We have found 

1209 that an effective way to state these requirements in a general way in to use the 

1210 phrase “ability to _” Comments are welcomed to add service requirements to 

1211 these sections. We know there are general service requirements that could be 

1212 added. Comments adding service requirements (especially those using our termi- 

1213 nology) are greatly appreciated. 

1214 4.3.4.1 Application Program Interface Services 
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1215 



1216 _ 

1217 Figure 4-9 - Directory Services Architecture 

1218 4.3.4.1.1 Directory Services 

1219 CRS: Rob, any additional service descriptions would be appreciated. You know 

1220 this area much better than I do. 

1221 Directory services allow an application to find the names and addresses of objects 

1222 and services available to the application. These services include: 

1223 — Ability to look up the name to be used to access a particular service 

1224 — Ability to look up the address of a named object 
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1225 4.3.4.1.2 Application to System Services 

1226 These are the services requested by the application that are performed by the 

1227 Application Platform on behalf of the application without the application actually 

1228 communicating directly with another application. Many of these services may 

1229 actually connect to some remote application but the details of the connection are 

1230 left up to the application platform. 

1231 These services will be provided by a relatively simple high level API. These ser- 

1232 vices include: 


1233 

( 1 ) 

File transfer 

1234 

( 2 ) 

Remote execution of commands 

1235 

( 3 ) 

Mail delivery 

1236 

( 4 ) 

Remote login 

1237 

( 5 ) 

Remote printer access 

1238 

( 6 ) 

Network status 


1239 — Ability to access remote or local systems using remote procedure calls 

1240 (RPC). When this type of access is provided, nearly all of the details of the 

1241 network connection and interaction are masked from the application. 

1242 4.3.4.1.3 Application to Application Service 

1243 There are three areas of application to application service requirements: 

1244 — RPC Services 

1245 — Simple Network Services 

1246 — Detailed Network Services 

1247 The RPC services allow an application to register with the network application 

1248 platform as the provider for a particular RPC Service. Once the service has been 

1249 properly registered, other applications can transparently request services using a 

1250 subroutine call. The details of communicating the service request to the applica- 

1251 tion that is registered to provide the service and the return of the response to the 

1252 requesting application are handled transparently by the Application Platform. 

1253 Applications making use of RPC services may not even be aware that the service 

1254 are being provided via an RPC mechanism. 

1255 The Simple Network Services are application to application services provided 

1256 using a simple set of interface routines. These will allow a wide variety of net- 

1257 working applications to be written that do not need to exercise control their net- 

1258 work access at a very complex level of detail. 

1259 In addition, these services should be provided over a wide variety of network tran- 

1260 sport mechanisms. Applications written exclusively using the simple services 

1261 should be portable across a wide variety of networking environments. 
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1262 Applications written using the simple network services may not be able to make 

1263 use of unique advantages of a particular physical networking scheme. To make 

1264 use of these network-specific features the Detailed Network Services must be 

1265 used. 

1266 The service requirements for the simple network services are intended to be the 

1267 minimum requirements to write a large subset of network applications. 

1268 The Simple Network Services sacrifice the capability to control every detail of the 

1269 network services in the interest of portability across networking environments 

1270 and applications simplicity. 

1271 The Detailed Network Services API allows the application to control over much 

1272 more detail of the network services. In addition, using the Detailed Network Ser- 

1273 vices an application may be able to make use of unique networking capabilities 

1274 available in particular networking environments. 

1275 4.3.4.1.3.1 RPC Services 

1276 These service requirements include: 

1277 — Ability to register as an RPC service provider 

1278 — Ability to wait for incoming requests 

1279 — Ability for an application using RPC services to control parameters such as 

1280 timeout 

1281 CRS: Someone who is an RPC whiz should beef this up with more detailed RPC 

1282 services 

1283 4.3.4.1.3.2 Simple Network Services 

1284 The services provided at the simple network interface are: 

1285 ( 1 ) Name resolution 

1286 ( 2 ) Connection oriented services 

1287 — Ability to indicate willingness to accept incoming connections 

1288 — Establishing and destroying connections 

1289 — Data transfer over connections 

1290 • Read 

1291 • Read with timeout 

1292 • Write 

1293 • Write with timeout 

1294 — Simple error handling 

1295 • Connection dropped notification 


Copyright © 1991 IEEE. All rights reserved. 

This is an unapproved IEEE Standards Draft, subject to change. 


78 


4 POSIX Open System Environment Services 



ENVIRONMENT INTERIM DOCUMENT 


P1003.0/D13 


1296 


• Connection read failure 

1297 


• Connection write failure 

1298 


— Ability to close a connection 

1299 


• Unconditionally 

1300 


• Only after all data has been received 

1301 

( 3 ) 

Connectionless services 

1302 


— Ability to indicate willingness to accept incoming requests 

1303 


— Ability to send requests 

1304 


• With acknowledgment 

1305 


• Without acknowledgment 

1306 


• Specified timeout 

1307 


— Ability to receive requests 

1308 


• Wait unconditionally 

1309 


• Wait with timeout 

1310 


— Ability to query as to whether any requests are available 

1311 


— Simple event notification 

1312 


• Lost request 

1313 


• Request acknowledgment 

1314 


— Simple error handling 

1315 


• General network failure 

1316 

(4) 

Support for server applications 

1317 


— Ability to register as the provider for a service 

1318 

( 5 ) 

Simple status inquiry 

1319 


— General network availability 

1320 

4.3.4.1.3.3 Detailed Network Service Requirements 

1321 

1322 

1323 

The services provided at the Detailed Networking Interface include all of the ser¬ 
vice requirements in the Simple Network Service Requirements plus the follow¬ 
ing: 

1324 

1325 

(1) 

Ability to query the network services to get detailed information about 
network configuration and status 

1326 

(2) 

Ability to specify performance metrics 

1327 

( 3 ) 

Ability to control routing 
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1328 

1329 

1330 

1331 

1332 

1333 

1334 

1335 

1336 

1337 

1338 

1339 

1340 


( 4 ) Ability to select between different network protocols 

( 5 ) Ability to negotiate capabilities 
— Required capabilities 

— Optional capabilities 

— Ability to determine the results of the negotiation 

(6) Capability to deliver information with different priorities 

( 7 ) Ability to request and process extended event notification 

(8) Ability to request and process extended error recovery including allowing 
the application to completely control error recovery. 

( 9 ) Ability to make full use of network resources for performance critical 
applications 

This should provide the application with the ability to completely control connec¬ 
tion oriented services and connectionless services. 


1341 4.3.4.1.4 Data Representation Services 

1342 — Ability to access all of the data representation and format conversion ser- 

1343 vices to allow an application to communicate with a wide variety of corn- 

1344 puter systems. 

1345 4.3.4.1.5 Distributed System Services 

1346 The services provided in this area include: 

1347 — The ability to identify available resources in a distributed system 

1348 — The ability to dynamically make use of the resources in a distributed sys- 

1349 tern. 

1350 — The ability to access files regardless of the physical location of the files. 

1351 — The ability to have reliable time services across all of the resources of the 

1352 distributed system. 


1353 

1354 

1355 

1356 

1357 

1358 

1359 


4.3.4.1.6 Network Management Services 

The services provided at the Network Management API are: 

( 1 ) The ability to manage 
— Network objects 

— Network relationships 
— Network security 

( 2 ) The ability to monitor and report on 
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1360 

1361 

1362 

1363 

1364 

1365 

1366 

1367 

1368 


— Network events 
— Network service alarms 
— Network security alarms 

( 3 ) The ability to log 
— Network events 

— Network availability 
— Network load 
— Network performance 

( 4 ) The ability to test network performance and reliability 


1369 4.3.4.2 External Environment Interface Services 

1370 At the external interface, there are several types of services that are provided. 

1371 These include: 

1372 — Data transfer and connectivity 

1373 — Routing and relay services 

1374 — Services provided by the application platform directly to an incoming con- 

1375 nection 

1376 — Network management and security services provided to other networks and 

1377 other nodes within a network 

1378 — Network management user interface 

1379 This clause does not address the user interface to the general network services 

1380 such as file transfer or mail sending. That is covered by the command interface 

1381 clause, 4 . 9 . As stated above, this clause covers the network management user 

1382 interface. 

1383 In addition, there are a number of other areas of external interface requirements 

1384 that are not covered in this guide. They include: 

1385 — Physical network interface connections 

1386 — Electrical specifications for network connections 

1387 — Specifications for physical network construction 

1388 These are important requirements that need to be specified when describing the 

1389 complete external interface of a computer system. There is a great deal of impor- 

1390 tant standardization in this area, but it is beyond the scope of this guide to cover 

1391 the subject. For more detail on these areas of the external environment interface, 

1392 see the “OMNICOM book.” 

1393 CRS: This is intended to be a reference to the 3 inch thick book that Andy brought 

1394 in... 
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1395 

1396 

1397 

1398 

1399 

1400 

1401 

1402 

1403 

1404 

1405 

1406 

1407 

1408 

1409 

1410 

1411 

1412 

1413 

1414 

1415 

1416 

1417 

1418 

1419 

1420 

1421 

1422 

1423 

1424 

1425 

1426 

1427 

1428 


4.3.4.2.1 Data Transfer and Connectivity 

Services required at the EEI in the area of data transfer and connectivity include: 

— The ability to connect and interoperate with other standards-based systems 
using standards-based protocols including X.25 and OSI. 

— The ability to connect and interoperate with systems using de facto net¬ 
working interfaces such as TCP/IP and UUCP 

— The ability to connect and interoperate with personal computer and works¬ 
tation networks. 

— The ability to interoperate with industry leading networking interfaces. 

4.3.4.2.2 Routing and Relay Services 

Services required at the EEI in the area of routing and relay capabilities include: 

(1) Ability to relay information through a system between like networks. 

(2) Ability to gateway information through a system between unlike net¬ 
works at a data transfer level. Examples of this type of gateway include: 

— Local Area Network (LAN) to LAN 

— LAN to Wide Area Network (WAN) 

— WAN to Global Area Network (GAN) 

— Networks to point-to-point connections 

— Point-to-point connections to networks 

(3) Ability to convert information from one format to another when transfer¬ 
ring between unlike computer systems or networks. Information that 
may need to be converted includes: 

— Mail messages 

— File contents 

— Printer file contents 

The primary requirement for the routing and gateway services is to make any 
necessary relays and gateways transparent to the applications and systems using 
the network. This requires complete gateways and relays. 

4.3.4.2.3 Services Provided by the Application Platform at the EEI 

These EEI services are those provided to incoming connections that are not 
directed to an end-user application or server. These incoming connections are 
directed to standard services that can be provided by systems. These services 
include: 

— Remote logon and terminal emulation 
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1429 — Remote execution of commands 

1430 — File transfer services 

1431 — Remote authentication 

1432 — Remote data access 

1433 — Remote status information 

1434 — Mail delivery services 

1435 — Directory services 

1436 To access these services each user does not need to provide an application on the 

1437 remote host. Simply by connecting to the service, the application platform will 

1438 provide the service. 

1439 4 . 3 A. 2.4 Network Management and Security Services 

1440 These EEI Services allow remote systems to be managed and monitored. Network 

1441 management services include: 

1442 — The ability to get network status information 

1443 — The ability to get network configuration information 

1444 — The ability to test network functionality 

1445 — The ability to make network configuration changes 

1446 The security services allow the system management to control access to system 

1447 resources and system inf ormation. Security services include: 

1448 — The ability to protect the system from intruders 

1449 — The ability to provide selective access to sensitive system resources 

1450 — The ability to manage the network security 

1451 4.3.4.2.5 Network Management and Security User Services 

1452 These EEI Services allow users and/or network administrators to control and 

1453 configure their network. These network management services include: 

1454 — The ability to get network status information 

1455 — The ability to get network configuration information 

1456 — The ability to test network functionality 

1457 — The ability to make network configuration changes 

1458 The security services allow the system management to control access to system 

1459 resources and system inf ormation. Security services include: 

1460 — The ability to protect the system from intruders 

1461 — The ability to provide selective access to sensitive system resources 
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1462 — The ability to manage the network security 

1463 4.3.5 Standards, Specifications, and Gaps 

1464 4.3.5.1 Current Standards in the POSIX OSE 

1465 CRS: These are the beginning of the standards sections. I still have yet to type in 

1466 all of the standards descriptions. Please provide comments regarding other ser¬ 
um vices listed above that have current or emerging standards. 

1468 CRS: Figure 4-6 from draft 12 is retained in this section. The box “posix applica¬ 
nt tion interface” is removed. The figure is referenced as part of the OSI protocol stack 

1470 in the standards table. 

1471 See Table 4 - 4 . 


1472 Table 4-4 - Current Networking Standards 

1473 _ 


1474 

Service 

API/EEI 

Specification 

Subclause 

1475 

Protocol Stack 

E 

ISO/OSI 

4.3.? (See Figure 4-10) 

1476 

Local Area Networking 

E 

ISO 802.3 

4.3.? 

1477 


E 

ISO 802.4 


1478 


E 

ISO 802.5 


1479 

Wide Area Networking 

E 

CCITT X.25 

4.3.? 

1480 

Directory Services 

E 

X.500 

4.3.? 

1481 

File Transfer 

E 

OSI FTAM 

4.3.? 

1482 

Message Handling 

E 

ISO/CCITT X.400 

4.3.? 

1483 


A 

APIA? 


1484 

Virtual Terminal 

E 

OSFVT 

4.3.? 

1485 

Network Management 

E 

ISO 9596 

4.3.? 

1486 


E 

ISO 9593 


1487 


E 

ISO/NMF 


1488 

Network Security 

E 

ISO 803.10 

4.3.? 

1489 

Distributed System Services 

E? 

ISO DP 

4.3.? 

1490 

Distributed Transaction Services 

E? 

ISP 10026, ISO 8587 

4.3.? 

1491 
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1492 4.3.5.2 Emerging Standards 

1493 See Table 4 - 5 . 


1494 Table 4-5 - Emerging Networking Standards 

1495 _ 


1496 

Service 

API/EEI 

Specification 

Subclause 

1497 

Mainframe Networking 

A 

IEEE P1003.10 

4.3.? 

1498 


A 

IEEE P1003.ll 


1499 

Network Security 

Both? 

IEEE P1003.6 

4.3.? 

1500 


Both? 

SIRS 233 


1501 


9 

X3T4 


1502 

Simple Network Interface 

A 

IEEE P1003.12 

4.3.? 

1503 

Detailed Network Interface 

A 

IEEE P1238.1 

4.3.? 

1504 


A 

X.400, APIA 


1505 


A 

IEEE P1003.10 


1506 

Distributed File Management 

A 

IEEE P1003.8 TFA 

4.3.? 

1507 

Directory Services 

A 

IEEE P1003.17 

4.3.? 

1508 

File Transfer 

A 

IEEE P1238 Bindings 

4.3.? 

1509 


A 

IEEE P1237 


1510 


9 

ECMA 127 


1511 

Message Handling 

E 

IEEE P1224 Bindings 

4.3.? 

1512 


A 

IEEE P1003.13 


1513 

Remote Procedure Call (RPC) 

A 

ECMA 127 

4.3.? 

1514 


A? 

ISO DIS 10148 


1515 


A 

IEEE P1237 


1516 

Distributed System Services 

? 

ECMA 127 

4.3.? 

1517 

Remote Data Access 

Both? 

SAG X3.T2 

4.3.? 

1518 

Distributed Transaction Services 

Both? 

IEEE P1003.ll 

4.3.? 

1519 

Print Services 

E? 

X3H3 

4.3.? 

1520 






1521 4.3.5.3 Gaps in Available Standards 

1522 See Table 4 - 6 . 
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1523 

1524 

Table 4-6 - 

Gaps in 

Networking Standards 


1525 

Service 

API/EEI 

Specification 

Subclause 

1526 

Local Area Networking 

E 

MIL-STD-1777 (IP) 

4.3.? 

1527 


E 

MIL-STD-1778 (TCP) 


1528 

PC Networking 

E 

X/Open PCI:SMB 

4.3.? 

1529 


E 

X/Open PCI:(PC)NFS 


1530 

Wide Area Networking 

E 

TCP/IP 

4.3.? 

1531 


E 

UUCP 


1532 

Mainframe Networking 

? 

X/Open CPIC 

4.3.? 

1533 

Network Management 

Both? 

X/Open System Management 

4.3.? 

1534 


E 

RFC-1098 (SNMP) 


1535 

Simple Network Interface 

A 

X/Open XTI 

4.3.? 

1536 

Detailed Network Interface 

A 

System V Streams 

4.3.? 

1537 


A 

Berkeley Sockets 


1538 

Directory Services 

E 

RFC-1034 (TCP/IP Domain 

4.3.? 

1539 



Naming) 


1540 

System Status 

E 

RFC-1194 (TCP/IP Finger) 

4.3.? 

1541 

File Transfer 

E 

MIL-STD-1780 (TCP/IP FTP) 

4.3.? 

1542 

Message Handling 

E 

MIL-STD-1781 (TCP/IP SMTP) 

4.3.? 

1543 

Virtual Terminal 

E 

MIL-STD-1782 (TCP/IP Telnet) 

4.3.? 

1544 

Network Time Protocol 

E 

RFC-1129 (Internet Time) 

4.3.? 

1545 

Distributed Transaction Services 

Both? 

X/Open XTP 

4.3.? 

1546 
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1547 


LAYER 7 
Application 


LAYER 6 
Presentation 


— r~ 

LAYER 5 
Session 
_ 1 _ 


LAYER 4 
Transport 


LAYER 3 
Network 


LAYER 2 
Data Link 


—I— 
LAYER 1 
Physical 

_l_ 

TRANSPORT 

SERVICE: 



PACKET SWITCHED (X.25) 


LAN: 

CSMA/CD 


LAN: 

Token Bus 


LAN: 

Token Ring 


1548 

1549 


Figure 4-10 - OSI Network Services Standards 


Copyright © 1991 IEEE. All rights reserved. 

This is an unapproved IEEE Standards Draft, subject to change. 


4.3 Network Services 


87 




P1003.0/D13 


GUIDE TO THE POSIX OPEN SYSTEMS 


Copyright © 1991 IEEE. All rights reserved. 

This is an unapproved IEEE Standards Draft, subject to change. 

88 4 POSIX Open System Environment Services 



ENVIRONMENT INTERIM DOCUMENT 


P1003.0/D13 


1550 4.4 Database Services 

1551 Responsibility: Sandra Swearingen 

1552 4.4.1 Overview and Rationale 

1553 This subclause describes an overview of an architectural framework for discussing 

1554 database management. It also describes the services provided to application pro- 

1555 grams and users, and it describes standards, current and emerging, that stand- 

1556 ardize those database services. 

1557 Database management is an important component of the POSIX Open System 

1558 Environment; in a large class of application programs, especially those used in 

1559 business, database access through a database management system plays a key 

1560 role. For portability and interoperability, an application using a database must 

1561 be isolated from the hardware and software retrieval methods as much as possi- 

1562 ble. Otherwise the application must have the data manipulation capability coded 

1563 in its own programs. This might be done if performance is a key issue and the 

1564 data is very unique. The cost is portability and interoperability. 

1565 The following metrics can be used to measure the performance of specific imple- 

1566 mentations of Database Management Systems. In some cases there are standard- 

1567 ized benchmarks, such as the Transaction Processing Council (TPC-A) perfor- 

1568 mance benchmark, that allow rigorous comparison of competing products. 

1569 — Time to load a database 

1570 — Time to recover a database after a failure 

1571 — Database throughput in “transactions per second” 

1572 — Maximum size database in bytes 

1573 — Maximum size of a table in rows 

1574 — Service response time 

1575 — Concurrency 

1576 — Maximum number of concurrent users 

1577 — Maximum number of concurrent transactions 

1578 4.4.2 Scope 

1579 Included within the component of database management are various structured 

1580 “data models,” including indexed files and network, relational, semantic, and 

1581 object-oriented databases. Specifically excluded from consideration are services 

1582 for accessing data that is not part of a database. This subclause discusses data- 

1583 base management services from both the application program and user points of 

1584 view. 
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1585 Database services provided to application programs by this component, for exam- 

1586 pie, include the ability to create, alter, or drop tables, records, and fields and the 

1587 ability to insert, select, and update data included in the structures above. 

1588 Included within this component are also utility capabilities such as database 

1589 administration services. 

1590 The list of standards below is comprehensive: there are no standards or emerging 

1591 standards in the database area that are excluded from the POSIX OSE. There are 

1592 no standards in this area that are known to be inconsistent with POSIX. 1 { 2 }. 

1593 4.4.3 POSIX OSE Database Services Reference Model D 

1594 4.4.3.1 Reference Model D 

1595 In this subclause, the conventional view of Database Management is related to 

1596 the POSIX reference model described earlier. 

1597 The application programmer’s view of the database model is introduced first. 

1598 Quite simply, an application program, through a Database API, requests database 

1599 services. For convenience in the following discussion, the agent responsible for 

1600 providing those services is called the Database Manager. The database manager 

1601 is responsible for providing the application access to the Database . See Figure 4 - 

1602 11. 

1603 This figure also demonstrates the concept of a Database Utility Program : one or 

1604 more special application programs, usually provided by a database vendor, that 

1605 perform utility services on the database. Such utilities might reorganize the data- 

1606 base, recover the database after a system failure, etc. 

1607 The traditional database model can be incorporated into the POSIX reference 

1608 model, as in Figure 4 - 12 . This depiction of the model shows that the database 

1609 manager is really just part of the overall POSIX Open System Environment and is 

1610 available to the application through the POSIX OSE API. 

1611 The model depicted in Figure 4 - 12 . is sufficient to describe an application 

1612 developer’s view of the POSIX OSE API in general, and the database API 

1613 specifically. The four lines labeled “Database API” represent the Database Appli- 

1614 cations Program Interface services, which are discussed in 4 . 4 . 4 . 1 . 

1615 4.4.3.2 Implementation Aspects d 

1616 Some real world considerations of the POSIX Reference Model were discussed in 

1617 3 . 6 . One of the real-world approaches described is “layering.” Note that in the 

1618 marketplace, Database Managers are often independently purchasable corn- 

1619 ponents that are effectively implemented as layers. Another consideration is 

1620 Database Manager portability. It is not a requirement that a a database manager 

1621 sit on top of a POSIX OSE API, but there is very important value to the user in 

1622 terms of portability if the database manager implementation does indeed sit on a 

1623 POSIX API. This means that the database manager itself is portable. It should be 
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1624 



1625 _ 

1626 Figure 4-11 - The Traditional Database Model 

1627 noted that there will probably be implementations available of database 

1628 managers that do not, in fact, sit on top of a POSIX API (or sit only partially on top 

1629 of a POSIX API), that nonetheless provide the user the same database API. Such 

1630 an implementation, using both POSIX API services and non-POSIX API services 

1631 was described as “expansion” (see 3 . 6 . 1 ). Note that even though the model is 

1632 drawn with only a single database manager, that does not imply that there may 

1633 only be a single database manager available to an application. In fact, the coex- 

1634 istence of several database managers on the same system is consistent with this 

1635 model, as is the ability of a single application to access two or more different data- 

1636 base managers. The following extensions to the above model are specifically 

1637 accommodated: 

1638 — There may be more than one database API. For example, there may be an 

1639 “SQL” API and an “ISAM” API. 

1640 — There may be more than one database manager implementation for each 

1641 different API. (For example, by two competing database vendors.) 

1642 — Applications may access more than one database manager. 

1643 This document has not described how a database manager is implemented in a 

1644 POSIX Open System Environment, nor is it within the scope of this document to 

1645 do so. It should be noted, though, that this model is very general and does not 

1646 constrain the implementor. This model supports a number of varying real world 

1647 implementation techniques, including: 

1648 — Application and database manager linked into a single process. 
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1649 
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Database Services EEI: 

— Remote Data Access Services 


_ * _ 

External 

Environment 


1650 _ 

1651 Figure 4-12 - POSIX Database Reference Model 


1652 — Database manager consisting of more than one process. 

1653 — Database manager consisting of a client part linked into the application 

1654 process and a server part running as a process on the same or another sys- 

1655 tern. 


1656 4.4.4 Service Requirements 

1657 The Database Manager described in the previous subclause provides services to 

1658 the Application Program via the Database API, and the Database Utility Pro- 

1659 grams provide other services (e.g., to human users such as a “Database Adminis- 

1660 trator”). This subclause describes the service requirements of all service users of 

1661 the system. It is intended to be a complete list of service requirements rather 

1662 than examples. Database Services are the specialized data services required to 

1663 create, access, and manage databases located on a processor node. A uniform use 

1664 of database services shall be available across POSIX-compliant machines. Users of 

1665 these services include end users and those charged with the ongoing management 

1666 of the information processing and database infrastructure. 

1667 4.4.4.1 Application Program Interface Services 

1668 This subclause describes the major categories of database services available at the 

1669 POSIX Application Program Interface (API). These services include: 
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1670 — Data Definition and Manipulation Services 

1671 — Data Access Services 

1672 — Data Integrity Services 

1673 — Miscellaneous Services 

1674 The following paragraphs clarify that these services should be provided for a large 

1675 class of objects, access methods, and types of database systems. 

1676 Types of Data Objects 

1677 Ability to perform the above operations on a variety of types of data 

1678 objects, such as text, graphics, image, documents, and voice. 

1679 Types of Access Methods 

1680 Ability to perform the above operations using a variety of access 

1681 methods, such as indexed sequential access, nonindexed sequential 

1682 access, and direct access. 

1683 Types of Database Management Systems 

1684 Ability to perform the above operations on a variety of types of file 

1685 and database management systems, and database management sys- 

1686 terns, such as relational, network, semantic, and object oriented 

1687 databases, and heterogeneous combinations of these database 

1688 management systems. 

1689 4.4.4.1.1 Data Definition and Manipulation Services 

1690 These services relate to the ability of application programs to define and manipu- 

1691 late data. These services are: 

1692 — Data definition — ability to create, alter, or drop tables, views, records, 

1693 fields, and/or data 

1694 — Data Manipulation — ability to insert, select, update, and delete tables, 

1695 views, records, fields, and data 

1696 4.4.4.1.2 Data Access Services 

1697 These services relate to the ability of application programs to interrogate data- 

1698 bases. These services are: 

1699 — Data Query Facilities — ability to specify search conditions, consisting of a 

1700 combination of select lists, predicates, and comparison operators 

1701 — Data Transparency — ability to transparently access data regardless of the 

1702 location of that data. 

1703 — Remote Data Access — ability to access and update remote data 
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1704 4.4.4.1.3 Data Integrity Services 

1705 These services relate to the ability of database management systems to protect 

1706 the databases from hardware and software malfunctions. 

1707 — Locking — ability to specify locking of data to some degree of granularity 

1708 — Consistency — ability to specify and execute check and referential con- 

1709 straints that help ensure data correctness 

1710 — Transaction Control — ability to specify commit and rollback commands 

1711 and guarantee serializability 

1712 — Synchronous Writes (Durability?) — ability to force the writing of data to 

1713 nonvolatile storage 

1714 4.4.4.1.4 Miscellaneous Services 

1715 These services relate to other services required for the automated management of 

1716 databases. 

1717 — Privilege Administration — ability to grant and revoke privileges for 

1718 accessing and administering data 

1719 — Exception Handling — ability to have applications that are interrupted and 

1720 notified of exception conditions, to receive control of the machine and take 

1721 action in response to these exception conditions—even if the action is to 

1722 “continue” 

1723 — Screen Definitions — ability to create screen definitions, and define, 

1724 display, and/or paint screens 

1725 — Reporting — ability to create formatted reports. 

1726 — Dynamic Facilities — ability to temporarily turn control of a database to 

1727 the end user for interactive access and manipulation of data, and then 

1728 return control to the application. 

1729 — Data Dictionary Services — ability to get data about the data (i.e., meta- 

1730 data) stored in the database. This allows users and applications to use the 

1731 database contents in a much more flexible way. These services allow a user 

1732 to create, access, and manage this metadata much in the same way as other 

1733 databases are maintained. 

1734 4.4.4.2 External Environment Interface Services 

1735 External Environment Interface services are required for distributed database 

1736 management systems. Also, to enable two or more databases to communicate 

1737 with each other, a common interchange format is required. See 4.5. 
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1738 4A.4.3 Database Resource Management Services 

1739 These services are not visible to the application programmer at the Database API. 

1740 These services are usually provided by Database Utility Programs. These ser- 

1741 vices include: 

1742 — Database Administration Services 

1743 — Database Recovery Services 

1744 — Distributed Database Management Services 

1745 — Heterogeneous Environment Support Services 

1746 4.4.4.3.1 Database Administration Services 

1747 Ability for a designated data administrator to structure and configuration manage 

1748 a database as a whole. The administrator allocates resources and monitors utili- 

1749 zation to assure that authorized users receive the proper services. Archive func- 

1750 tions, journaling, and logging services are available to the user and administrator 

1751 on a selective basis. 

1752 4.4.4.3.2 Database Recovery Services 

1753 Ability to decide that there has been a failure, allow recovery from failure, and 

1754 permit a slave copy to become a master copy. 

1755 4.4.4.3.3 Distributed Database Management Services 

1756 Supports the partitioning and partial replication of the databases. 

1757 4.4.4.3.4 Heterogeneous Environment Support Services 

1758 Permits local database systems to be of different types (e.g., inverted list, 

1759 hierarchical, network, relational) by providing translators between the local data- 

1760 base form and a general “network language.” 

1761 4.4.4.3.5 Flagger 

1762 Ability for programmers to be alerted about any code that does not conform to the 

1763 standard in question, or about any code that is not processed in a conforming 

1764 manner. 

1765 4.4.5 Standards, Specifications, and Gaps 

1766 There are currently four database standards, either completed or under develop- 

1767 ment. These are the relational data language SQL, a network data language 

1768 called NDL, the Information Resource Dictionary System (IRDS) for data diction- 

1769 ary work, and a Remote Data Access (RDA) protocol. Table 4-7 summarizes the 

1770 service requirements provided by the various standards. 
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1771 

1772 

Table 4-7 - 

Database Standards 


1773 

Service 


Specification 

Subclause 

1774 

Data Definition and Manipulation Services 

SQL: 

ISO 9075 

4.4.5.1 

1775 

Data Access Services 


ANSI X3.135 


1776 

Data Integrity Services 


ANSI X3.168 


1777 

Data Definition and Manipulation Services 

NDL: 

ISO 8907 

4.4.5.1 

1778 

Data Access Services 




1779 

Data Integrity Services 




1780 

Miscellaneous Services (Data Security and 

IRDS: 

ISO DP 10027.N2642, 

4.4.5.2 

1781 

Integrity, Exception Handling, Screen 


(IRDS Framework) 


1782 

Definitions, Reporting, Dynamic Facilities, 


ISO DP 8800 N2132, 


1783 

Data Dictionary Services) 


(IRDS Interfaces) 


1784 

Database Resource Management Services 


ANSI X3.138 


1785 

(Database Administration, Recovery From 




1786 

F ailure) 




1787 

External Environment Interface Services 

RDA: 

ISO/IEC DP 9759 

4.4.5.2 

1788 






1789 4.4.5.1 Current Standards in the POSIX OSE 

1790 This subclause describes the current accepted standards that apply to this area. 

1791 SQL Standard Database Language 

1792 ANSI X3.135.1 (ISO 9075, FIPS 127) 

1793 ANSI X3.168 

1794 There is a lot of activity by ANSI and ISO in this area. The standards referenced 

1795 above are all related, but may not all be “current” at the time you read this guide. 

1796 The base document is the 1989 ANSI document. ISO and FIPS documents based on 

1797 it should be used. Earlier ISO and FIPS documents are based on earlier versions 

1798 of the ANSI document and consequently may not be consistent with the latest 

1799 ANSI document. Beware of this in making decisions about which of the standards 

1800 are relevant to your decisions. These standards, developed in 1982-1989 by the 

1801 ANSI X3H2 Database Committee, specify data access capabilities based on “struc- 

1802 tured query language” and the relational database model. 

1803 The X3.135 standard provides for many of the services described in 4.4.4, includ- 

1804 ing Data Definition, Manipulation, and Integrity. It provides for two levels of 
isos compliance: the weaker Level 1 and the more capable Level 2. 

1806 While X3.135 deals with SQL independently of programming language, X3.168 

1807 binds, or embeds SQL within the programming languages COBOL, FORTRAN, Pas- 

1808 cal, PL/1, C, and Ada. 
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1809 Work is currently planned by ANSI and ISO to include “generalized triggers,” 

1810 “generalized assertions,” “recursive expressions,” “escape from SQL,” subtables, 

1811 and support tools for object oriented and knowledge-based systems. 

1812 NDL Standard Database Language 

1813 ISO 8907 

1814 ANSI X3.133 

1815 This standard, developed in 1981-1986 by the ANSI X3H2 Database Committee, 

1816 specifies a data definition language (DDL) and data manipulation language (DML) 

1817 for network model databases. This work is an outgrowth of the 1978 CODASYL 

1818 specifications. 

1819 This standard provides for many of the services described in 4.4.4, including Data 

1820 Definition, Manipulation, Access, and Integrity. The above services apply only to 

1821 network databases (i.e., not to relational or semantic databases.) 

1822 No follow-on NDL activities are being conducted by ISO or ANSI. 

1823 4.4.5.2 Emerging Standards in the POSIX OSE 

1824 This subclause describes the activities currently in progress to further standard- 

1825 ize this area. 

1826 Remote Data Access (RDA) Protocol 

1827 ISO DP 9579: 

1828 Part I, Generic Remote Database Access — DP 2 

1829 Part II, SQL Specialization — DP 1 

1830 This standard, developed by the ECMA Technical Committee on Database Stan- 

1831 dards, TC22, submitted to ISO in 1985, specifies a protocol that allows remote 

1832 access and updating, via OSI communications protocols, of relational databases or 

1833 of database systems that support SQL. 

1834 This standard provides for the Data Transparency, Remote Data Access, and Sup- 

1835 port for Heterogeneous Environment requirements described in 4.4. This protocol 

1836 is aimed at relational databases and other database types that provide access via 

1837 relational interfaces such as SQL. 

1838 Much work is planned on in this area by the ISO committee ISO TC97/SC21/WG3. 

1839 A specific area of current interest is a generic RDA that uses a nonspecific data- 

1840 base language (i.e., not SQL.) 

1841 Information Resource Dictionary System (IRDS) 

1842 ANSI X3.138 FIPS Pub 156, April 5, 1989 

1843 ANSI X3H4/90-28 (draft, 4 Apr 90) 

1844 IRDS Export/Import File Format 
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1845 ISO DP 10027 N2642 (1988) IRDS Framework 

1846 ISO DP 8800 N2132 (1988) IRDS Services Interfaces 

1847 These standards are being developed by the ANSI X3H4 Database Group and the 

1848 ISO/IEC /JTC 1/SC21 Working Group 3. Both groups are addressing the general 

1849 area of data dictionaries, but, as described below, the emphases of the activities 

1850 differ. 

1851 The ANSI group addresses, primarily, the user interface area, that is, how does a 

1852 human user access the Data Dictionary Services described in 4.4.4. 

1853 The ISO groups concentrate more on the service interfaces (APIs) among lower 

1854 level components and utilities of the database model. 

1855 Differences in scope and incompatibilities exist between the model being 

1856 developed by ISO and the model approved by ANSI. They are independently 

1857 developing the Services Interface, and an export/import facility. 

1858 4.4.5.3 Gaps in Available Standards 

1859 There are two significant areas described in 4.4.4 as requirements that are not 

1 860 addressed by standards: 

1861 — Methods to access data such as hashing and indexed sequential access to 

1862 data is not currently standardized. There is no consensus in the standards 

1863 community as to whether such standardization would be beneficial. 

1864 — Standardization of semantic and object oriented models have also not taken 

1865 place, though groups like the ANSI Database system study group (DBSSG) 

1866 are currently investigating the feasibility of standardization in these areas. 

1867 — I/O Services such as screen generation. 

1868 — Management and control of database services. Also include all gaps (all 

1869 services without standards). 

1870 4.4.6 OSE Cross-Category Services 


1871 4.4.6.1 Security 

1872 Ability to specify access control mechanisms. 
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1873 4.4.7 Related Standards 


1874 The standards and activities described in this subclause are related to the above 

1875 and may also be relevant to your activities. 

1876 There are several areas closely related to the Database area that are worth con- 

1877 sidering with respect to standardization. 

1878 The first area to consider is the communications and networking area. Interoper- 

1879 ability for distributed applications or the use of distributed databases may indi- 

1880 cate the use of communications software adhering to networking standards. See 

1881 4.3 for further discussion of that area. (Specifically consider the following stan- 

1882 dards described in that subclause: 


1883 ISO/IEC 9804.3 

1884 ISO/IEC 9805.3 

1885 ISO 8824 

1886 
1887 


(OSI CCR services) 

(OSI CCR protocol) 

Information Processing Systems — OSI — 
Specification of Abstract Syntax Notation One 
(ASN.l) 


1888 ISO 8825 

1889 

1890 


Information Processing Systems — OSI — 

Specification of Basic Encoding Rules for Abstract 
Syntax Notation One (ASN.l) 


1891 The second area to consider is transaction processing. That area goes further in 

1892 addressing the total requirements for distributed applications. See 4.10. 
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1893 4.5 Data Interchange Services 

1894 Responsibility: Richard Scott 

1895 4.5.1 Overview and Rationale 

1896 The Data Interchange/Information Exchange components of the POSIX Open Sys- 

1897 tem Environment provide specialized support for the exchange of data between 

1898 applications or components of applications. Without support for data interchange, 

1899 problems can arise when attempts are made to move data between different 

1900 operational environments or between two related applications. More specifically, 

1901 data interchange problems arise in each of the five following situations: 

1902 — Movement of a single application program and its associated data between 

1903 operational environments, 

1904 — Movement of data between cooperating application software within the 

1905 same operational environment, 

1906 — Movement of data between cooperating application software operating in 

1907 differing operational environments, 

1908 — Movement of data between related, but not cooperating, application 

1909 software within a single operational environment, and across differing 

1910 operational environments. 

1911 From the global view, the data interchange components can provide the means to 

1912 satisfy the needs in each of these situations. These standards need to define phy- 

1913 sical formats, data formats, code sets, and data descriptions that are consistent 

1914 across all implementations of the POSIX Open System Environment. 

1915 4.5.2 Scope 

1916 The data interchange component of the POSIX Open System Environment 

1917 includes standard services, protocols, and data formats required to ensure that 

1918 data can be interchanged between related application software. Physical media 

1919 formats are beyond the scope of the POSIX Open System Environment. 

1920 4.5.3 Reference Model 

1921 The Data Interchange Services relate directly to the POSIX Open System Environ- 

1922 ment reference model that was presented in Figure 3-1. Figure 4-13 shows the 

1923 components of the reference model that are significant for data interchange. The 

1924 reference model defines the conceptual relationships required to provide these 

1925 facilities. It should not be viewed as a description of an implementation. The key 

1926 entities within the figure are the Application Software, the Application Platform, 

1927 and the External Environment. To satisfy the data interchange service require- 

1928 ments, the POSIX Open System Environment must permit application software to 

1929 transfer data to and from the external environment. 
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1930 



1931 _ 

1932 Figure 4-13 - Data Interchange Reference Model 

1933 The application software requests this transfer through the Application Program 

1934 Interface. In response to those requests, the data interchange components of the 

1935 Application Platform handle conversions to and from standard formats and the 

1936 transfer of the information across the External Environment Interface (EEI). The 

1937 EEI, which defines the format specifications required to support data interchange, 

1938 can be divided into Data Description Protocols and Data Format Protocols. Data 

1939 Description Protocols provide a means to identify the data that is present. Data 

1940 Format Protocols provide the storage representation of the actual data. 

1941 Today, this model is only partially supported by standards. Physical formats are 

1942 fairly well standardized. Some work is beginning on data format protocols stan- 

1943 dards, particularly in the networking area. At this time, no general standards 

1944 exist to support Data description protocols. 

1945 4.5.4 Service Requirements 

1946 This subclause details the Data Interchange Services and protocols that are 

1947 required to support application portability and interoperability. Subclause 4.5.4.1 

1948 describes the API service requirements. 4.5.4.2 describes the EEI service (i.e., pro- 

1949 tocol) requirements. 

1950 Data interchange is one of the components of the POSIX Open System Environ- 

1951 ment that is now just beginning to evolve. At this time, the general requirements 

1952 for services are understood, but there is little general existing practice that can be 

1953 pointed to as showing that current service requirements are both necessary and 

1954 complete. Most existing practice is limited to a specific application domain. As a 


Copyright © 1991 IEEE. All rights reserved. 

This is an unapproved IEEE Standards Draft, subject to change. 


102 


4 POSIX Open System Environment Services 






ENVIRONMENT INTERIM DOCUMENT 


P1003.0/D13 


1955 developing area, data interchange represents gaps in both the definition of service 

1956 requirements and standards. The data interchange component is, none the less, 

1957 critical for supporting application portability and interoperability. The data 

1958 interchange service requirements are currently described to the extent possible at 

1959 this time in their evolution. More detail will be added in future revisions of this 

1960 guide. 

1961 4.5.4.1 Application Program Interface Services 

1962 The API services to support data interchange need to provide the ability to store 

1963 and retrieve data using the formats and protocols provided at the data inter- 

1964 change EEI. 

1965 At this time little work has been directed at defining API-level service require- 

1966 ments for data interchange. Data interchange API services need to provide a 

1967 means to request that specific data be represented using the EEI services defined 

1968 below. Progress in this area is similar to the development of the networking area. 

1969 Initial standards defined protocols and only after those were in use has attention 

1970 shifted to providing a standard mechanism for requesting those networking ser- 

1971 vices. 

1972 4.5.4.2 External Environment Interface Services 

1973 This section identifies the EEI services required to support data interchange. 

1974 These services are all in the form of protocol and format definitions. As shown in D 

1975 Figure 4-13, these protocols include: 

1976 — Character Sets and Data Representation 

1977 — Data Format Protocols 

1978 — Data Description Protocols 

1979 These protocols are required to support the exchange of information between 

1980 application software entities, both within a single application platform and 

1981 between application platforms. 

1982 4.5.4.2.1 Character Sets and Data Representation 

1983 The ability to support Character Sets and Data Representation is crucial to pro- 

1984 viding effective data interchange between application software operating under 

1985 differing language and cultural conventions. These services add facilities to the 

1986 POSIX Open System Environment to identify the character set and data represen- 

1987 tations associated with textual data. A detailed description of the requirements 

1988 in this area can be found in 5.1. 

1989 4.5.4.2.2 Data Format Protocols 

1990 The data format protocols need to provide the ability to identify the representa- 

1991 tion of the data in a manner that is independent of the specific execution environ- 

1992 ment. The data format protocol layer adds attributes that describe the physical 
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1993 characteristics of the data that must be known to properly retrieve the data value, 

1994 given the storage formats that are native on the hardware/software environment 

1995 where the data is used. The complete attribute information required to decipher 

1996 that data value includes: 

1997 — Detailed storage format for the value 

1998 — The data value in an environment-neutral format 

1999 The data format protocols protect applications from hardware/software differences 

2000 between environments. Specifically, the protocols ensure that data remains 

2001 stable when moving between environments where the character set, word size, or 

2002 byte ordering may differ. 

2003 4.5.4.2.3 Data Description Protocols 

2004 Data description protocols provide the ability to share data between related appli- 

2005 cation software entities, even if they were not specifically written to cooperate. 

2006 Building upon the facilities provided by the previous two Data Interchange EEI 

2007 Services, data description protocols provide a means of associating a name or 

2008 other identifier with the individual data elements in a standard manner. This 

2009 permits an application program to correctly identify data that was created by an 

2010 unrelated application. To date, most standards in this area have limited them- 

2011 selves to specific application areas and no general solution has been provided. 

2012 4.5.5 Standards, Specifications, and Gaps 

2013 See Table 4-8. 

2014 4.5.5.1 Current Standards in the POSIX OSE 

2015 4.5.5.1.1 International Standards 

2016 Open Document Architecture (ODA)/Open Document Interchange Format 

2017 (ODIF) 

2018 The ODA/ODIF standard (ISO 8613 Parts 1-8) provides a standard for the struc- 

2019 tures used to represent documents. The ODA model defines a comprehensive 

2020 description of a documents format. It supports both reproduction of the original 

2021 document and also editing and formatting of the document. 

2022 Part 5 of the ISO ODA standard specifies the interchange format for ODA docu- 

2023 ments; specifically ODIF. ODIF is an ASN.l (ISO 8825) based presentation of the 

2024 ODA document. 

2025 Standard Generalized Markup Language (SGML) 

2026 SGML (ISO 8879) is a language that allows users to precisely define the structure 

2027 of a document. The key difference between SGML and ODA/ODIF is that the 

2028 former provides the flexibility to define custom document types. 
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2029 Table 4-8 - Data Interchange Standards 

2030 _ 


2031 

Service 

Specification 

Subclause 


2032 

Data Description Protocols ODA/ODIF 

ISO 8613 Parts 1-8 

4.5.5.? 

D 

2033 

SGML 

ISO 8879 

4.5.5.? 

D 

2034 

EDIFACT 

ISO 9735 

4.5.5.? 

D 

2035 

STEP 

ISO DP 10303 

4.5.5.? 

D 

2036 

EDIFACT 

ANSI X.12 

4.5.5.? 

D 

2037 

IGES 

NBSIR 86 

4.5.5.? 

D 

2038 

VHDL VHSIC 

IEEE P1076 

4.5.5.? 

D 

2039 

Data Format Protocols ODA/ODIF 

ISO 8613 Parts 1-8 

4.5.5.? 

D 

2040 

SGML 

ISO 8879 

4.5.5.? 

D 

2041 

CGM 

ISO 8632 

4.5.5.? 

D 

2042 

CGM 

ANSI X3.122-1986 

4.5.5.? 

D 

2043 

STEP 

ISO DP 10303 

4.5.5.? 

D 

2044 

EDIFACT 

ISO 9735 

4.5.5.? 

D 

2045 

EDIFACT 

ANSI X.12 

4.5.5.? 

D 

2046 

IGES 

NBSIR 86-3359 

4.5.5.? 

D 

2047 

VHDL VHSIC 

IEEE P1076 

4.5.5.? 

D 

2048 

CDIF 


4.5.5.? 

D 

2049 

GDSII 


4.5.5.? 

D 

2050 __ 






2051 Computer Graphics Metafile (CGM) 

2052 CGM (ISO 8632, ANSI X3.122-1986) provides a standard means for the storage and 

2053 exchange of computer graphics. Graphic information is stored in a device- and 

2054 resolution-independent fashion that can support both the display and the mani- 

2055 pulation of the data. 

2056 Electronic Data Interchange (EDI) 

2057 The EDI standards [ISO 9735 (EDIFACT), ANSI X.12] provide support for the 

2058 exchange of structured business data. EDI is typically used to transfer business 

2059 documents such as purchase orders, invoices, promotional announcements, and 

2060 electronic funds transfer information. 

2061 4.5.5.1.2 Regional Standards 

2062 None. 

2063 4.5.5.1.3 National Standards 

2064 None. 
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2065 4.5.5.2 Emerging Standards in the POSIX OSE 

2066 4.5.5.2.1 International Standards 

2067 Standard for the Exchange of Product Model Data (STEP) D 

2068 STEP (ISO DP 10303) is a neutral mechanism capable of completely representing D 

2069 product data throughout the life cycle of a product. The completeness of this d 

2070 representation makes it suitable not only for file exchange, but also as a basis for D 

2071 implementing and sharing databases of archiving. D 

2072 4.5.5.2.2 Regional Standards 

2073 None. 

2074 4.5.5.2.3 National Standards 

2075 None. 

2076 4.5.5.3 Gaps in Available Standards 

2077 4.5.5.3.1 Standards and Specifications Outside the POSIX OSE 

2078 Most standards activity in the data interchange area has been isolated to special- 

2079 ized application areas. These activities have attempted to support data inter- 

2080 change by limiting the scope of the effort to a specific type of data. These industry 

2081 standards include: 

2082 4.5.5.3.1.1 Government/Legal Standards 

2083 Initial Graphics Exchange Specification (NBSIR 86-3359) 

2084 IGES is used heavily in the exchange of graphical information between applica- 

2085 tions. 

2086 4.5.5.3.1.3 De Facto Standards 

2087 CASE Data Interchange Format (CDIF) D 

2088 The CDIF Technical Committee is developing a data interchange format to serve D 

2089 as an industry standard for exchanging information between Computer-Aided D 

2090 Software Engineering (CASE) tools. CDIF is an EIA-endorsed initiative. It D 

2091 assumes that two or more tools may interface asynchronously with each other and D 

2092 will transfer information from one to another via “CDIF files.” The types of infor- D 

2093 mation that may be contained in these files is defined by the CDIF Conceptual D 

2094 Models. D 
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2095 Graphic Design System II (GDSII) CAD Exchange Format 

2096 CAD exchange format. 

2097 Hardware Description Language (VHDL VHSIC) 

2098 The VHDL standard (IEEE P1076) defines a representation for the exchange of 

2099 CAD representations of electronic circuits. 

2100 4.5.5.3.2 Unsatisfied Service Requirements 

2101 None of these standards addresses a general means to handle application data in 

2102 a manner to ensure portability between environments. The closest attempt is the 

2103 effort just beginning in POSIX.8 to define a means within the network interface to 

2104 provide data portability. However, even this effort is not attempting to solve the 

2105 broader issue of interoperability of multiple applications. The existing standards 

2106 have all evolved to support the interchange of specific types of data between 

2107 separate applications. Support for general data portability is not addressed by 

2108 existing standard, except for ISIS, which does not appear to have caught on. 

2109 4.5.6 OSE Cross-Category Services 

2110 Not applicable. d 


2111 4.5.7 Related Standards 

2112 The following standards are related to the services covered in this clause as they 

2113 address some of the services described in section 4.6.4 at some level. Each of 

2114 these related standards are addressed fully as part of another service category. 


2115 

ASN.l 

ISO 8824 

2116 


ISO 8825 

2117 

MHS 

ISO/CCITT X.400-1984 

2118 


ISO/CCITT X.400-1988 


Abstract Syntax Notation (Clause 4.3) 
ASN.l Basic Encoding Rules (Clause 4.3) 

Message Handling System (Clause 4.3) 
Message Handling System (Clause 4.3) 


2119 4.5.8 Open Issues 

2120 Data interchange support must address hardware/software differences between 

2121 environments. The key concerns in transporting data that must be addressed will 

2122 include the character set, word size, and byte ordering for the operating environ- 

2123 ment along with a accurate identification of the data value. 

2124 The data portability standards adopted within POSIX Open System Environment 

2125 need to define data formats that will enable applications to create data that can 

2126 be used read and properly interpreted on differing operating environments and by 

2127 other application software. 
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2128 4.6 Windowing System Services d 

2129 Responsibility: Marti Szczur and Ruth Klein 

2130 4.6.1 Overview and Rationale 

2131 Human user interface standards are considered in this clause. The user interface 

2132 is a key component of all computer systems that support direct human-machine 

2133 interaction. Until recently, most computer operating systems interpreted com- 

2134 mands that were typed in from the keyboard of an alphanumeric computer termi- 

2135 nal. Special purpose applications, such as those for CAD/CAM, have always 

2136 presented user interfaces based on series of menus or pointing at visual displays 

2137 with tablets and lightpens. The availability of low-cost bitmapped graphic works- 

2138 tations and personal computers has lead to the proliferation of graphical user 

2139 interfaces (GUIs), windowing technologies, generic commands, and an assortment 

2140 of selection techniques (e.g., mouse, track ball, tablets). In several of these tech- 

2141 nologies de facto standards are emerging and becoming informally accepted by the 

2142 user community, and with more frequency, mandated for use in systems being 

2143 developed within government agencies and private industry. The primary 

2144 motivations for considering human/computer interaction standards and their rela- 

2145 tion to POSIX standards include: 

2146 — The existence and popularity of windowing systems 

2147 — The requirement for development of applications that take advantage of the 

2148 windowing system environment 

2149 — The requirement of many users and manufacturers for a basic consistency 

2150 in the presentation and behavior of human computer interaction across 

2151 multiple graphics platforms 

2152 As the windowing system technology evolves within the graphics environment, 

2153 the differences between windowing services and graphic services becomes less dis- 

2154 tinct. The distinction for purposes of this document is that graphic services are 

2155 associated with providing general purpose interfaces for creating virtually any 

2156 kind of two- and three-dimensional graphics (e.g., GKS for 2 -D and PHIGS for 3 -D). 

2157 HCI services certainly utilize graphic technologies, but are limited to providing 

2158 graphics related to window-based user interfaces and specifications on how 

2159 human users may interact with an application within a window environment. 

2160 The graphic services are addressed independently in 4 . 7 . 

2161 Performance metrics are used in the specification of HCI components. It is 

2162 intended that (eventually) a set of metrics that will be sufficient to characterize 

2163 all of the services defined above. 

2164 — Screen width—effective horizontal width of screen 

2165 — Screen height—effective vertical height of screen 

2166 — Screen depth—effective depth of screen (i.e., bit width, gray scale) 
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2167 — Screen resolution—size in units of 10 6 

2168 — Application display latency—time to satisfy a display request measured in 

2169 units of milliseconds; the interval begins with release of the request from 

2170 the (possibly remote) application. The interval ends with completion of 

2171 requested service. 

2172 4.6.2 Scope 

2173 Standards and standards initiatives in the user interface area cover a wide area, 

2174 ranging from keyboard layout to screen management. In this clause, the follow- 

2175 ing specific standards are considered: 

2176 — Protocols for window management on a local or remote display device 

2177 — Application Program Interfaces (API) for such protocols 

2178 — HCI drivability features that define a common subset of “look and feel”; i.e., 

2179 appearance, screen positioning, and behavior of human/computer interac- 

2180 tion objects within windows on a graphic screen 

2181 — Language-independent functional specifications and appropriate associated 

2182 language bindings for the display, manipulation, and management of 

2183 interaction objects within windows on a graphic screen 

2184 — Command-language interface that may be entered interactively by the 

2185 human user or retrieved from a stored procedure. 

2186 — Language-independent functional specifications and appropriate associated 

2187 language bindings required to support character (non-bitmapped) termi- 

2188 nals. 

2189 — Language-independent functional specifications and appropriate associated 

2190 language bindings for the translation, manipulation, and management of 

2191 command statements (or messages). 

2192 Standards relating to the following are not considered: 

2193 — Graphics; see 4 . 7 . 

2194 — Keyboard layout (out of scope for HCI Services) 

2195 — Network transport protocols; see 4 . 3 . 

2196 — Hardware device interfaces (out of scope for HCI Services) 

2197 4.6.3 Reference Model 

2198 This subclause identifies the entities and interfaces specific to the construction of 

2199 an HCI architecture. This architecture is consistent with, and extends the archi- 

2200 tecture of, Section 3 . As illustrated in Figure 4 - 14 , the interface components 

2201 involved in the user interface process are divided into two groups, called the 

2202 external environment interface (EEI) and the application program interface (API). 
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2203 



2204 _ 

2205 Figure 4-14 - Windowing Reference Model 

2206 The EEI is concerned with the communication with the user via the physical HCI 

2207 devices (e.g., keyboard terminal, mouse, display screen). The applicable EEI stan- 

2208 dards are driven primarily in support of user and data portability across different 

2209 application platforms, standards and guidelines are intended to define a minimal 

2210 set of commonality in human user interfaces, which will eliminate problem areas 

2211 such as: 

2212 — Error provoking inconsistencies 

2213 — Misleading expectations about the results of user actions 

2214 — Gross inconsistencies in the high level user model or metaphor 

2215 — Incompatible motor control tendencies 

2216 The drivability concept derives its name from the concept of “driving” an inter- 

2217 face. A frequently cited analogy is the automobile. Having a standard location for 

2218 the clutch, brake, accelerator pedals, ignition key, and steering wheel allows a 

2219 driver to move between car models with relative ease (until he/she has to roll 

2220 down the window, turn on the lights or windshield wipers!) Similarly, the EEI 

2221 drivability guidelines will provide standards for human user interfaces that will 

2222 ensure ease of moving between application platform models. For example, which 
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mouse click causes an interaction object (e.g., radio button) to be selected or how a 
scroll bar should behave would be candidates for standard EEI specification. 

The API is concerned with the interface between the application semantics and 
the HCI services. It is the interface between the application software and the 
application platform and is defined primarily in support of application portability. 
These services provide functions for creation and manipulation of visual display 
objects such as menus, buttons, scrollbars, and dialog boxes. In addition, these 
functions allow information about user actions to flow back to the application 
software; for example, when the user has selected an item from a menu. This 
information about user actions is known as an event. Applications that require 
communication with the human user are inherently event-driven. That is, associ¬ 
ated with an application’s dialog window (i.e., a window in which a user response 
is expected) is a main event loop waiting for the user to make a selection that will 
trigger an operation to be performed by the application. 

The API will support a specific user interface policy, which will define the 
application’s “look and feel.” Although the specific look and feel need not be stan¬ 
dard across application platforms (i.e., different implementations of the API may 
have unique styles) the API definition shall ensure that the application software 
can be ported across POSIX platforms; and the API shall support the EEI drivabil- 
ity guidelines, enabling human users to easily operate the application across plat¬ 
forms. 

Elements of the HCI Architecture are Application Software elements, Application 
Program Interface (API) elements, and External Environment Interface (EEI) ele¬ 
ments. These elements are linked by the use of common concepts and definitions 
associated with the HCI entities, interfaces, services, and standards. 

4.6.3.1 Application Software Elements 

Application Entity Elements include: 

( 1 ) Window System Server 

The Window System Server provides a function that handles communica¬ 
tion connections from clients, demultiplexes graphics requests onto the 
screens, and multiplexes input back to the appropriate client. Applica¬ 
tions and other programs that use basic windowing services are called 
“clients.” Many clients may talk to the same server. All application 
requests to write to the screen must go through the server via the basic 
windowing services. The server is independent of operating system, pro¬ 
gramming languages, or network communication. 

( 2 ) Window Manager 

A Window Manager provides a uniform method for manipulating win¬ 
dows, which includes a basic set of window management capabilities that 
allow for development of alternative and/or user-preferred window 
managers. Required human user capabilities shall include but are not 
limited to: 
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— Resize window 
— Move window 

— Push/pop window to top/bottom 

— Shrink window to a reduced visual representation of window (i.e., fre¬ 
quently referred to as an icon of the window) 

( 3 ) Local and Remote Applications 

These applications are clients that provide the functions required to per¬ 
form the specific task(s) that the human user needs to achieve (e.g., 
spreadsheets, scientific analysis systems, CASE tools, process and control 
tasks.) 

4.6.3.2 Application Program Interface (API) Elements 

The API are language binding specifications that define the services available to 
the application programmer. API Elements are: basic window services, toolkit 
window services, and dialog services. 

4.6.3.3 External Environment Interface (EEI) Elements 

The EEI elements are specifications (and in some cases, aspects of physical 
objects) that define how the application platform interacts with the external 
world. Note that application software, as defined here, interacts with the outside 
world only via the application platform. 

External Environment Interface Elements include: 

— Display Device Specifications 

— Data Protocol Format 

— User Drivability Guidelines (e.g., “look and feel” of window interface) 

— Keyboard Device Specification 

— Selection Device Specification (e.g., mouse, graphics tablet, touch screen) 

— Command-language Definition (syntax and semantics guidelines) 


4.6.4 Service Requirements 

Human-Computer Interaction (HCI) Services provide a controlled interface 
between the application-specific software and the user-interface-specific (i.e., HCI) 
software, allowing each to be designed and implemented separately. Users of 
these services include all POSIX system users and those charged with maintaining 
the processor and human interface communication. A common, standardized 
human/computer interaction for applications shall be available to users across all 
POSIX Open Systems Environments. 


Copyright © 1991 IEEE. All rights reserved. 

This is an unapproved IEEE Standards Draft, subject to change. 


4.6 Windowing System Services 


113 



P1003.0/D13 


GUIDE TO THE POSIX OPEN SYSTEMS 


2299 Services shall support raster (i.e., bitmapped) graphics displays. Methods for sup- 

2300 porting vector graphics displays can be addressed, but are not mandatory. 

2301 4.6.4.1 Application Program Interface Services 

2302 Application services include those services made available to the application 

2303 developer to separate the application functions from the HCI functions as much as 

2304 possible. They include such areas as screen management, windowing, and user 

2305 input device services. 

2306 These standard services support requirements for application portability, 

2307 software commonality, application interoperability and data communications 

2308 transparency. 

2309 A programmer shall have access to the following services from an application via 

2310 language bindings. 

2311 4.6.4.1.1 Basic Window Services 

2312 The basic window services, callable from client applications, support a window- 

2313 based user interface. They should be based on a “client-server” model. The server 

2314 is a program that handles communication connections from clients, demultiplexes 

2315 graphics requests onto the screens, and multiplexes input back to the appropriate 

2316 client. Many clients may talk to the same server. All application requests to 

2317 write to the screen must go through the server via the basic windowing services. 

2318 The major functional areas are: 

2319 — Window Management 

2320 — Presentation Management 

2321 — Event Handling 

2322 — Error Handling 

2323 — Interclient Communications 

2324 — Input Device Management: Keyboard, Pointing Device 

2325 — Screen Management 

2326 — User Preferences Management 

2327 — Server Connection Management 

2328 The following functions are available under each functional area. 

2329 Window Management 

2330 Functions available for Window Management are: 

2331 — Create a window, map a window onto the screen, delete a window (includes 

2332 support for character-based emulator window) 
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2333 — Manipulate a window (move, resize, change view precedence) 

2334 — Manipulate window attributes (set, get, change; attributes may be related 

2335 to appearance, redraw performance, event handling, or change authority) 

2336 — Seize and relinquish control over the Server for display purposes (permits 

2337 uninterrupted client output; output requests from other clients will be 

2338 queued and displayed later) 

2339 Presentation Management 

2340 Functions available for Presentation Management are: 

2341 — Associate data with a window (context manager functions and association 

2342 table functions) 

2343 — Manipulate the graphics context for a given object (create a graphics con- 

2344 text, obtain current graphics context, change graphics context, etc.) 

2345 — Get and set fonts (load font, list fonts, unload font, etc.) 

2346 — Draw graphics primitives (draw arc, draw line, fill rectangle, clear rec- 

2347 tangular window, clear entire window, etc.) 

2348 — Manipulate window cursors (create, destroy, assign, change, etc.) 

2349 — Draw text and obtain text metric information 

2350 Event Handling 

2351 The basic window services support application requirements to respond to the 

2352 human user’s actions, rather than forcing the human user to respond to the appli- 

2353 cation in a rigid, serialized manner. This requirement necessitates that a pro- 

2354 gram either ( 1 ) be capable of handling any one of a number of events at any single 

2355 point in time, or ( 2 ) attach a routine to each event to be called automatically when 

2356 that event occurs. There is a separate set of events for each window used by the 

2357 application. An application selects the events for a particular window, maps the 

2358 selected events to the window, and reads events from the event queue as they 

2359 occur. There are three major types of events: 

2360 — Input device events (button press event, keypress event, etc.) 

2361 — Window management events (window exposure event, colormap event, etc.) 

2362 — Client message events (selection data transferred (by another application) 

2363 event, private interclient communication event, etc.) 

2364 Functions available for Event Handling are: 

2365 — Select events 

2366 — Map events to a window 

2367 — Get information about events 

2368 — Send events 
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Error Handling 

Functions available for Error Handling are: 

— Get error message 

— Get error description 

— Set error event handler routine 

Interclient Communication 

The basic window services are required to be network transparent to an applica¬ 
tion or client. This means that an application on one host may write to the 
display screen connected to another host without being aware that networking is 
involved. The basic window services handle the network connections and follow 
the protocols necessary for the application to interact with the display. This con¬ 
vention allows redistribution of applications in a networked system with no effect 
on the application software. Therefore, an application client cannot assume that 
another client can open the same files or seize the same processing environment. 
Interclient communication via the server has three forms: 

— Properties 

Clients may associate arbitrary information with a window; generally used 
for communication between a client and the window manager. 

— Selections 

Selections are selected by the user out of one client’s window, then “sent” to 
another client and displayed in the second client’s window. 

— Cut Buffers 

Cut Buffers are a specialized form of communication. It is possible to 
receive notification when a cut buffer (property) is set. 

Functions available for Interclient Communication are: 

— Manipulate window properties (list, delete, change, get, etc.) 

— Set and get selections 

— Manipulate cut buffers 

Input Device Management 

Functions available for Input Device Management are: 

— Receive keyboard input and pointing device button events 

— Gain exclusive control of keyboard or pointing cursor 

— Track the pointing cursor 

— Change Server-wide keyboard mappings 
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2403 — Set and get keyboard and pointing device preferences 

2404 Screen Management 

2405 Functions available for Screen Management are: 

2406 — Manipulate color using colormaps (copy, change, install, deinstall, get 

2407 default, etc.) 

2408 — Get, display, and manipulate bitmapped screen images 

2409 — Screen saver functions (blanking screen on idle) 

2410 — Retrieve display information (default colormap, number of display planes, 

2411 screen width and height, etc.) 

2412 User Preferences Management 

2413 The services and data structures used for managing user preferences are provided 

2414 and collectively referred to as User Resource Management. There may be up to 

2415 four sets of options that need to be read and merged: 

2416 — The human user’s defaults stored in the root window’s user resource 

2417 manager property 

2418 — The human user’s defaults stored in a user’s defaults file 

2419 — The application program’s defaults 

2420 — The command line arguments 

2421 Functions available for User Preferences Management are: 

2422 — Set and get preference data 

2423 Server Connection Management 

2424 Functions available for Server Connection Management are: 

2425 — Control access to the Server [add host to the access control list (ACL), list 

2426 ACL, disable ACL, etc.] 

2427 — Connect and disconnect a client from a Server (and the display controlled 

2428 by the Server) 

2429 — Obtain Server implementation information 

2430 — Flush output buffer to Server and wait for Server to process all events in 

2431 the output buffer 

2432 4.6.4.1.2 Toolkit Window Services 

2433 The Toolkit Window services provide a mechanism for runtime access to a library 

2434 of visual objects. A visual object is a graphical display object (i.e., interaction 

2435 object) with associated software that receives input from human users (typically 

2436 via a keyboard and a pointing device) and communicates with applications and 

2437 other visual object software. The graphical representation of a visual object can 
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be modified to reflect the results of application processing. Examples of visual 
objects are graphical push buttons, check boxes, and editing boxes. (Note: The 
term used within the X Window System community to define visual objects is 
“widgets.”) 

Toolkit Window services are provided for two reasons: 

— To allow application software to directly utilize a visual object library 

— To allow application-specific visual objects to be created and added to the 
widget library (Note: creating a visual object includes writing software 
that uses the Toolkit services) 

Therefore, Toolkit services may be logically divided into two categories, with some 
overlap: Visual Object Interface Services, which are called by an application or 
dialog service, and Visual Object Programming Services, which are called by the 
visual object software. 

An application may use Toolkit Window services to: 

— Perform toolkit initialization/exit 

— Set up visual object resources 

— Create/delete a visual object 

— Display a visual object 

— Add/remove application-specific routines to be called by a visual object 
(event callbacks) 

— Retrieve/modify the state of a visual object 

— Turn control over to the toolkit for user input processing 

A visual object software program may use Toolkit Window services to: 

— Manage child visual objects (a child visual object is a visual object that is 
displayed inside of another visual object) 

— Manage window events, timer events, and file input events 

— Handle visual object geometry (sizing, positioning, child visual object place¬ 
ment) 

— Handle user input 

— Manage visual object resources 

— Translate an event into an action 

— Manipulate graphics contexts 

— Manipulate pixmaps (pixel arrays—used to display a graphical object by 
turning pixels on and off) 

— Manage memory associated with HCI 

— Handle errors associated with HCI 
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2474 — Allow inter-visual object communication (via the selection mechanism) 

2475 — Initiate other visual object routines (visual object event callbacks) 

2476 — Initiate application-specific routines that have been associated with the 

2477 visual object by the application (application event callbacks) 

2478 4.6.4.1.3 Dialog Services 

2479 Dialog services provide functions to support high-level HCI management for appli- 

2480 cations with the primary goal of delivering human user inputs to the application 

2481 program and application-driven information to the human user. The dialog ser- 

2482 vices allow for a separation of the user interface specifications from the applica- 

2483 tion program. For example, there are many applications that are not concerned 

2484 with whether a user entry object is a pull-down menu or a scrollable list. These 

2485 applications are only interested in what the user specified or selected from the 

2486 user entry object (i.e., the parameter value), which will then trigger some action 

2487 by the application. To support this notion, a single dialogue function might be 

2488 specified for displaying a window made up of a composite of visual display objects, 

2489 such as radio buttons, text key-in objects, and scrollable text lists. The applica- 

2490 tion program does not need to manage or understand what the look, location, or 

2491 visual feedback of any of these items will be. The dialog function has access to the 

2492 presentation information required to display the specified window and it handles 

2493 the display of the application specified window. Another dialog service would pro- 

2494 vide a high-level event loop that returns the user specified input as an application 

2495 parameter value. 

2496 The services provide simplicity over the degree of freedom available in Basic and 

2497 Too lki t Window Services. Most User Interface Management Systems (UIMSs) pro- 

2498 vide dialog services to fulfill their requirement of separation of user interface from 

2499 application software. 

2500 These services are subdivided into: 

2501 — Window services: provide services used to initialize the window service, 

2502 create and delete windows with predefined associated visual objects, and 

2503 manipulation of the pointing cursor. They include services that allow the 

2504 application to communicate directly with the human user via modal or 

2505 modeless windows. 

2506 — Visual object manipulation services: provide services used to access the HCI 

2507 designed by the application HCI designer, display the visual objects defined 

2508 by the HCI, and associate them with application-tied inputs and outputs. 

2509 — Event control services: provide services to allow the application to define a 

2510 set of events and handle triggered events in one of two ways: 

2511 (1) Wait on the occurrence of any event, processing triggered events one 

2512 at a time from an input queue (event-driven method) 

2513 (2) Attach to each event a function that is automatically executed when 

2514 the event is triggered (callback method) 
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2515 4.6.4.2 External Environment Interface Services 

2516 These services provide support for the actual elements with which the human 

2517 user physically interacts. These functions provide services in three areas: 

2518 — HCI: provides definition of the presentation and behavior of the visual 

2519 display objects, command language definition (syntax and semantics), 

2520 specifications related to keyboards, selection devices, audio and video 

2521 input/output devices. 

2522 — Information Interfaces: provides specification of user resource data formats, 

2523 containing presentation and action information pertaining to visual display 

2524 objects. 

2525 — Network Interfaces: provides protocol services for data transport, which is 

2526 basically the bottom six layers of the OSI model 

2527 4.6.4.3 Interapplication Entity Services 

2528 These services provide support for general conventions and specifications for 

2529 interaction between HCI components. The services provide support for general- 

2530 ized network/multisession services, such as message handling between HCI com- 

2531 ponents, intermediate language definition, and a standard definition of the format 

2532 used for saving the presentation, behavior, and action information about HCI 

2533 objects. 

2534 4.6.4.4 Windowing Resource Management Services 

2535 These services provide general management functions across the HCI components, 

2536 which include system administration-oriented functions (i.e., management of 

2537 human/computer interfaces within the scope of the administrator, such as setting 

2538 up defaults and human user customization functions. For instance, it is impor- 

2539 tant to allow reconfiguration and addition of terminals and displays without 

2540 affecting the application interface.) These resource management services are 

2541 independent from the OLTP Resource Management Services defined in 4.10.4.4. 

2542 4.6.5 Standards, Specifications, and Gaps 

2543 Standards that relate to the user reference model presented earlier are considered 

2544 here. Related standards that might be relevant for one or more of the interface 

2545 components will also be mentioned. 

2546 4.6.5.1 Current Standards in the POSIX OSE 

2547 No current international or national standards exist for the HCI Services, pri- 

2548 marily due to the recent emergence of the windowing technology. However, 

2549 several standard activities are underway and referenced under 4.6.5.2. 

2550 There is a de facto standard for the base window system. The X Window System 

2551 windowing protocol and the Xlib functional interface to the protocol were 
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2552 developed at Massachusetts Institute of Technology. Development is continuing 

2553 under the aegis of the X Consortium, a group of interested parties in the computer 

2554 industry and computer manufacturers. Relevant documents from the X Consor- 

2555 tium are “X Window System Protocol, X Version 11,” “Xlib - C language X Inter- 

2556 face,” “X Toolkit Intrinsics - C Language Interface,” and “Bitmap Distribution 

2557 Format 2.1.” 

2558 The X Window System protocol and functional interface are considered to be de 

2559 facto standards in the base window system area because of their widespread 

2560 adoption by major computer vendors and industry groups. 

2561 Within the government, the National Institute of Standards and Technology 

2562 (NIST) issues Federal Information Processing Standards (FIPS) that require pur- 

2563 chases made by the United States Government to adhere to certain standards. 

2564 NIST has adopted the X Window System Version 11 Release 3’s X Window System 

2565 protocol, Xlib, Xt Intrinsics, and Bitmap Distribution Format as FIPS 158. This is 

2566 a noncompulsory (i.e., voluntary) standard. 


2567 Table 4-9 - Windowing Standards 

2568 _ 


2569 

Service 

Specification 

Subclause 


2570 

Basic Window Services 

de facto: X Window System 

4.6.5.? 

D 

2571 


emerging: ANSI X3K13.6 


D 

2572 

Toolkit Window Services 

de facto: X Window System 

4.6.5.? 

D 

2573 


emerging: ANSI X3K13.6 


D 

2574 


emerging: IEEE POSIX.2 { ref) 


D 

2575 


emerging: IEEE POSIX. 1 {2} 


D 

2576 

Dialog Services 

Gap 

4.6.5.? 

D 

2577 

EEI Services 

emerging: ANSI X3V1.9 

4.6.5.? 

D 

2578 


emerging: ISO/IEC JTC 1/SC18/WG19 


D 

2579 


emerging: ANSI HSF-HCI 


D 

2580 


emerging: ISO TC159/SC4/WG5 


D 

2581 


emerging: P1201.2 


D 

2582 

Interapplication Entity Services 

Gap 

4.6.5.? 

D 


2583 Window/Character Resource Gap 4.6.5.? 

2584 Management Services 

2585 _ 


2586 4.6.5. 

2587 MRS: 

2588 — 

2589 — 

2590 

2591 

2592 


2 Emerging Standards in the POSIX OSE 

This subclause still needs work. 

ANSI X3K13.6. Currently developing an X Protocol standard. 

ANSIX3V1.9. User-System Interfaces and Symbols: Working on a ISO/IEC 
Standard 9995, Keyboard Layouts for Text and Office Systems. Also work¬ 
ing on the Voice Messaging User Interface Forum (VMUIF). This is a mir¬ 
ror standards effort with ISO/IEC JTC 1/SC18/WG19. 
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2593 — ISO/IEC JTC 1/SC18/WG19. User-System Interfaces and Symbols. Working 

2594 on developing standards for user interfaces and symbols associated with 

2595 text and office systems. 

2596 — ANSI HFS-HCI. Working on drafts on the design process, information 

2597 presentation, forms-based dialogs, and window-based interaction. 

2598 — ISO TC159/SC4/WG5. Software Ergonomics and Man-Machine Dialog: 

2599 Working on developing parts of the ISO Standards 9241, Ergonomics of 

2600 Visual Display Terminals. Their areas of concentration are software 

2601 ergonomics, dialogue principles, dialogue styles, methods for evaluating 

2602 software usability, coding and formatting of information, and terminology 

2603 — IEEE P1201. Application and User Portability: Chartered to develop stan- 

2604 dards that facilitate application and user portability in the X Windows 

2605 environment. P1201.1 is involved in defining a set of virtual toolkit ser- 

2606 vices that would be independent of any windowing system. P1201.2 is 

2607 involved in defining drivability guidelines. 

2608 — ANSI CODASYL. Working draft available for Forms Interface Management 

2609 Systems (FIMS), which covers the interface between a programming 

2610 language and any form fill-in application on a computer or terminal screen. 

2611 4.6.5.3 Gaps in Available Standards 

2612 — Object Definition File Format: There are no standards addressing the for- 

2613 mat used for describing the “look and feel” of HCI objects. 

2614 — Toolkit Services 

2615 — Dialog Services 

2616 — Interapplication Entity Services 

2617 — Window/Character Resource Management Services: A standard definition 

2618 of the format used for saving the presentation, behavior and action infor- 

2619 mation about HCI objects would provide a vehicle for exchanging HCI infor- 

2620 mation between software tools, such as User Interface Management Sys- 

2621 terns (UIMSs) and Interface Design Tool (ITDs). 


2622 4.6.6 OSE Cross-Category Services 

2623 4.6.6.1 Security 

2624 This section should address the security aspects of HCI and would include: 

2625 — Authentication of person at login 

2626 — Authentication of person when a service request is made to a client applica- 

2627 tion 

2628 — Provisions for visual labeling of sensitive material 
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2629 — Option selections available in support of sensitive activities 

2630 — Prevention of moving data (cut/past) from a more protected security 

2631 environment to a less protected environment 


2632 4.6.7 Related Standards D 

2633 Currently, the basic windowing services provide a certain level of graphics func- 

2634 tionality, but the existing and proposed graphics standards (e.g., PHIGS, GKS) pro- 

2635 vide a much more comprehensive solution to graphic support. As the graphics 

2636 and windowing technologies evolve, this distinction between the windowing and 

2637 graphics services will continue to be blurred. For instance, proposals are already 

2638 being developed that provide extensions to the X Window System that support 3- 

2639 D graphics (i.e., PEX, PHIGS Extensions), and implementations of GKS are 

2640 currently available that use the X Window System to create the graphics. 


2641 4.6.8 Open Issues 

2642 — Audio input/output 

2643 — Video input/output 

2644 — Security 

2645 — Desktop 

2646 The Desktop, or HCI graphical shell, is a specification for the HCI work sur- 

2647 face (i.e., the whole display screen). 

2648 The desktop provides the user with a visual interface to available computer 

2649 resources. A desktop may be characterized as a visual analog of the POSIX 

2650 shell. It provides access to system resources, such as devices and files, and 

2651 provides methods to start applications. Desktops typically also provide a 

2652 set of often used utilities such as a calendar, a notepad, etc. The desktop is 

2653 an important component of the look and feel of a human user interface, but 

2654 the current state of the industry is too immature for any standardization to 

2655 materialize on a desktop specification in the immediate future. 

2656 NOTE: There are some valid arguments for defining some requirements for standards at 

2657 this level. The goal is to enable a user to easily go between application platforms and 

2658 operate common functions in a similar manner. 
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2659 4.7 Graphics Services 

2660 Responsibility: John Williams 

2661 HLJ: This is a full clause replacement for Draft 13. It is not further cliff marked. D 

2662 4.7.1 Overview and Rationale 

2663 Graphics Services are key components and play an important role in the POSIX 

2664 Open Systems Environment as it is used today in many different areas of indus- 

2665 try, business, government, education, entertainment, and most recently, the 

2666 home. The number of applications is growing rapidly, with increasing graphics 

2667 capabilities. Some of these areas are user interfaces, computer-aided drafting and 

2668 design, electronic publishing, plotting, simulation, animation, scientific visualiza- 

2669 tion, art, and process control. The use of pictorial graphics provides a more intui- 

2670 tive interface and thus facilitates man/machine interaction. 

2671 Graphics has become a routine part of most organizations today, ranging from 

2672 hardcopy graphs and charts to user interfaces and complex 3-D visualizations 

2673 incorporating video and sound. The graphics technology of rendering objects has 

2674 become dramatically more realistic and hence is used by engineers, architects, 

2675 artists etc., to enable them to see precisely what their final products, whether 

2676 automobiles or buildings, will look and behave like under real-world conditions. 

2677 Graphics has allowed dramatic improvements in the “look and feel” of user inter- 

2678 faces and the trend is towards increasing use of these interfaces to interact with 

2679 computers graphically, via windows and icons and this reduces the time involved 

2680 in learning to use a computer. 

2681 Standardization of graphics services has many benefits for application developers, 

2682 users, and systems integrators. The underlying motivations for considering 

2683 graphics standards and their relation to the POSIX Open Systems Environment 

2684 include: 

2685 (1) Portability: In order to protect investment and achieve independence 

2686 from a particular technology and a particular supplier of technology, por- 

2687 tability at both hardware and software levels is necessary. There are 

2688 many aspects of portability within graphics, all of which are potential 

2689 money and time savers. 

2690 — Applications portability 

2691 — Graphics package portability 

2692 — Host machine independence 

2693 — Device independence 

2694 • input devices: dials, mouse, tablets etc. 

2695 • output devices: plotters, raster, vector etc. 

2696 — Window system independence 
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2697 

2698 

2699 

2700 

2701 

2702 

2703 

2704 

2705 

2706 

2707 

2708 

2709 

2710 

2711 

2712 

2713 

2714 

2715 

2716 

2717 

2718 

2719 

2720 

2721 

2722 

2723 

2724 

2725 

2726 

2727 


— Programming language independence 
— Programmer portability 
— User portability 

(2) Interoperability/Distributed Graphics: In order to allow applica¬ 
tions to execute on one machine and display graphics on remote display 
servers, standard graphics protocols are necessary. This allows for 
display of graphics on machines that are incapable of executing particu¬ 
lar types of applications and it also facilitates graphics conferencing. 

(3) Graphics Data Exchange: In order to share or exchange graphical 
information between diverse applications, standard graphics data 
exchange mechanisms are necessary. 

This clause presents a reference model for this component and describes the ser¬ 
vices provided to application programmers and users. It also describes the 
current national/international standards, emerging standards, de facto standards, 
and any existing gaps that need new standardization efforts. 


4.7.2 Scope 

Included within this component are standards in the graphics area that address 
the following topics : 

— Application Program Interface (API) Standards 

— Language Bindings Standards 

— Metafile and Archive Standards 

— Device Independent Interface/Protocol Standards 

— Computer Graphics Reference Model 

— Conformance Testing of Implementations of Graphics Standards 

— Distributed Graphics Standards 

— Imaging Standards 

— Performance Metrics Standards 
The standards not addressed here are: 

— Data Exchange Standards 

— Graphical User Interface Standards 

— Window Management System Standards 
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2728 
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4.7.3 Reference Model 

Over the past decade many computer graphics standards have been developed. 
While they are similar in concepts, their underlying reference models are dif¬ 
ferent. This restricts the degree to which the standards are compatible. By pro¬ 
ducing a reference model to which all future graphics standards are to adhere, 
compatibility of graphics standards is assured. 

Formal work on the Computer Graphics Reference Model (CGRM) standard is in 
progress within the ANSI X3H3.2 committee. It is an international standard that 
explains the relationships between existing graphics standards and defines rela¬ 
tionships between standards in computer graphics and those in other areas. It 
will form the basis for the next generation of computer graphics standards. 
Broadly speaking, CGRM provides a framework within which relationships 
between standards can be described. 

There are five types of standards in the current family: 

— Application Program Interface (API) Standards: These define a program¬ 
ming interface for application programmers. GKS, GKS-3D, PHIGS, and 
Xlib are examples of standards in this area. 

— Metafile and Archive Standards: These standards define representations of 
graphics for storage and transfer between systems. These are basically file 
format and file transfer encoding standards. CGM (Computer Graphics 
Metafile) and PHIGS Archive files are of this type. 

— Device Independent Interface Standards: These standards define the inter¬ 
face between device-independent graphics systems software and one or 
more device-dependent graphics device drivers. CGI (Computer Graphics 
Interface) is the standard in this area. 

— Language Binding Standards: API and device interface standards are func¬ 
tional specifications defined independently from particular programming 
languages. Each standard has attached language binding standards that 
state how the functionality should be accessed from a variety of program¬ 
ming languages. 

— Framework Standards: These include the standardization of a reference 
model for computer graphics, conformance criteria, and the registration of 
graphical items. 

The CGRM describes the current family of graphics standards in terms of the fol¬ 
lowing four levels of abstraction: 

— Application Level: This is the level at which applications-related informa¬ 
tion is composed into abstract graphics related to the application. 

— Virtual Level: At this level, the graphical output to be displayed is 
described in terms of output primitives 

— Logical Level: At this level, the information necessary to render a primitive 
on a particular device is assembled. 
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2769 — Physical Level: This level is associated with a particular output device and 

2770 a collection of input devices. The physical level need not correspond to real 

2771 devices such as a pen plotter. There could be further layers of the system 

2772 between the physical level and the hardware, such as the window system. 

2773 _ 



2774 _ 

2775 Figure 4-15 - Computer Graphics Reference Model Level Structure 

2776 The Application Program Interface (API) is the interface between the application 

2777 and the graphics system. There are also interfaces to metafiles and archives and 

2778 to the operator. Here the operator need not mean human operator, but the user of 

2779 the graphics system; for example, the window system. 

2780 The Computer Graphics Reference Model can be incorporated into the POSIX OSE 

2781 reference model as depicted in Figure 4-16. It provides the context for the discus- 

2782 sion of graphics services and shows that the graphics services is a component of 

2783 the overall POSIX OSE and is available to the the application through the POSIX 

2784 OSE API. 

2785 The entities and interfaces specific to the graphics services are identified in this 

2786 clause. 
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2787 



Graphics 

Services 

API 


Graphics 

Services 

EEI 


2788 _ 

2789 Figure 4-16 - POSIX OSE Graphics Service Reference Model 


2790 The entities are: 


2791 (1) Application Software, such as CAD/CAM/CAE applications, imaging 

2792 applications, electronic publishing, etc. 


2793 (2) Application Platform, which consists of graphics libraries such as GKS, 

2794 PHIGS and Xlib. 


2795 

2796 

2797 


(3) External Environment, consisting of external entities with which the 
application platform exchanges information such as input devices, X/PEX 
servers, hardware buffers, etc. 


2798 The interfaces are: 


2799 (1) Application Program Interface (API), which is the programming 

2800 interface between the application and the application platform. It stand- 

2801 ardizes the conceptual model, calling sequence, functions, and syntax 

2802 that a programmer uses to develop a graphics application. Each API 

2803 standard has an attached language-binding standard that allows the 
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2804 functionality to be accessed from a variety of programming languages. A 

2805 standard API in conjunction with a standard language binding promotes 

2806 application portability, by isolating the programmer from most hardware 

2807 peculiarities and providing language features readily implemented on a 

2808 broad range of processors. Examples of APIs in the graphics services area 

2809 are GKS, PHIGS, PIK, PostScript, etc. 

2810 (2) External Environment Interface (EEI), which is the interface 

2811 between the application platform and the External Environment 

2812 described earlier. In the graphics services area these can be device 

2813 drivers that are used for communication between the device-independent 

2814 and the device-dependent functions as well as protocols and file formats. 

2815 The standardization efforts in the graphics area focus on these two interfaces. 

2816 4.7.4 Service Requirements 

2817 4.7.4.1 Graphics Concepts 

2818 Computer Graphics Services can be discussed in terms of the following fundamen- 

2819 tal graphics concepts: 

2820 Output Primitives 

2821 The output primitives are the building blocks used to construct graphical objects 

2822 for display or storage in an archive file. Common output primitives are: 

2823 — Line 

2824 — Polyline used to represent a series of straight lines from a set of points. 

2825 — Marker is a special symbol used to represent semantics of graphical objects. 

2826 — Fill area is an area with an edge and an interior which may be filled with a 

2827 solid color or some form of pattern or hash. 

2828 — Text is an output primitive used to represent strings in two or three dimen- 

2829 sional space. 

2830 — Annotation text is text that is always displayed facing the viewer. 

2831 — Cell arrays are areas with rectangular grids which can take on individual 

2832 colors. 

2833 — Triangle strip is a set of triangles defined by a particular ordering of ver- 

2834 tices. 

2835 — Quadrilateral mesh is a set of quadrilaterals defined by a grid of vertices. 

2836 — Surfaces: NURBS (Nonuniform Rational B-Spline) 

2837 — Curves: NURBS (Nonuniform Rational B-Spline) 

2838 — Conics: Circles, ellipses, parabolas, and hyperbolas 
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2839 Primitive Attributes 

2840 Attributes of primitives determine the style of the display of the primitive. For 

2841 example, lines and edges may have different line styles such as dotted or dashed, 

2842 text may have different fonts, orientation, and character spacing. A polymarker 

2843 may be an asterisk or a small triangle. They all may be red in color. General 

2844 type attributes that apply to almost any output primitive are color, visibility, pic- 

2845 kability, and highlight method. 

2846 Input Primitives 

2847 Input primitives or logical devices are virtual devices designed to insulate the 

2848 application from the real input devices. Logical devices include picking devices, 

2849 locator devices, choice devices, valuator devices, etc. In terms, of actual devices, a 

2850 locator device might be associated with the first mouse button. 

2851 Input Model 

2852 The input model describes how input primitives and logical devices are related to 

2853 physical input devices and the degree of control provided to the application over 

2854 the devices. For example, one control choice might be how feedback is echoed to 

2855 the operator when a logical locator device is attached to a depressed mouse but- 

2856 ton. The feedback might be a rectangular cursor or the highlighting of geometry 

2857 as a cross-hair cursor moves over it. When the button is released the device coor- 

2858 dinates are placed in the locator data record and an event is placed in an event 

2859 queue for which the application can check asynchronously. The method the appli- 

2860 cation uses to determine if a device has data for it is usually described in terms of 

2861 modes. A com m on mode is event mode. The application waits a finite time for 

2862 some event to appear in a queue. If no event comes in the finite time, the applica- 

2863 tion does other processing and eventually comes back to check the queue with the 

2864 wait for some event. If an event appears, the application determines what type it 

2865 is and gets the data for that type of event. For a pick device, the data might be all 

2866 possible graphical primitives that could intersect some aperture, possibly 

2867 specified in the device coordinate system. 

2868 Coordinate Systems and Clipping 

2869 Part of the graphics services is a means to utilize various coordinate systems. 

2870 Graphical output has to be described to the graphics system in terms of some 

2871 coordinate system, relevant to the application and presented to the display device 

2872 in terms of its own coordinate system, the device coordinate system. It is unlikely 

2873 that these two coordinate systems will be the same. A graphics system may 

2874 therefore involve a number of coordinate systems and hence the need to define 

2875 transformations between them. Some standard types of transformations are seal- 

2876 ing, rotating, translating, reflecting, and projection, such as parallel and perspec- 

2877 tive. They are used to manipulate objects in a coordinate system and to map from 

2878 one coordinate system to another. The coordinate systems commonly used are 

2879 modeling coordinates, world coordinates, view-reference coordinates, normalized 

2880 projection coordinates, and device coordinates. 


Copyright © 1991 IEEE. All rights reserved. 

This is an unapproved IEEE Standards Draft, subject to change. 


4.7 Graphics Services 


131 



P1003.0/D13 


GUIDE TO THE POSIX OPEN SYSTEMS 


2881 Clipping is the process of specifying a region in space and restricting graphical 

2882 output to that region. Only those primitives that define objects in that region will 

2883 have their output displayed. 

2884 Output Model 

2885 The output model is the concept of how graphics objects are created, displayed, 

2886 and controlled on output devices. The output model defines how to position and 

2887 organize objects on the screen, and the visual state of these objects such as visible 

2888 or invisible, hidden lines removed or not removed, picture matches retained struc- 

2889 ture, picture not consistent with retained structure, etc. 

2890 More specifically, the output model concept is made up of the: 

2891 — Transformation pipeline 

2892 — Rendering pipeline 

2893 — Retained structures 

2894 — Nonretained structures 

2895 — Graphics state 

2896 — Window systems 

2897 Error Handling 

2898 TBD 

2899 Storage/Archiving 

2900 TBD 

2901 4.7.4.2 Graphics Requirements 

2902 The graphics service requirements of all users of this system can be generalized 

2903 as: 

2904 — The ability to create, delete, and modify output primitives. 

2905 — The ability to specify and edit the primitive attributes globally and indivi- 

2906 dually. 

2907 — The ability to transform (i.e., scale, translate, rotate, reflect, project, etc.) 

2908 primitives for construction of more complex objects and for arrangement in 

2909 the viewing space. 

2910 — The ability to create and manipulate a database of primitives, to define and 

2911 edit attributes, to create and combine transformations, and to selectively 

2912 control the display of graphics primitives. 

2913 — The ability to display graphical objects constructed in a retained database, 

2914 or the ability to display primitives immediately, or to display from both a 

2915 retained database and immediately. 
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2916 — The ability to apply lighting and shading algorithms to collections of graph- 

2917 ical objects with multiple light types and sources. 

2918 — The ability to prepare display data and control the timing of the actual 

2919 display of the display data. On some systems this is referred to as frame 

2920 buffer control. 

2921 — The ability to store and retrieve graphical objects from files. 

2922 — The ability to control input devices and retrieve data from input devices. 

2923 — The ability to direct output to a meta-file and retrieve graphics data from a 

2924 meta-file. 

2925 — The ability to inquire about all aspects of the graphics environment; e.g., 

2926 the state of the system at any given time, the actual capabilities of a given 

2927 hardware platform, the attributes and primitives supported by a given 

2928 implementation, etc. 

2929 — The ability to distribute graphics. 

2930 — The ability to control errors. 

2931 4.7.4.3 Application Program Interface Services 

2932 The major categories of graphics services available in the POSIX OSE API area 

2933 include: 

2934 — 2 -D graphics API services 

2935 — 3 -D graphics API services 

2936 — Device interface API services 

2937 — Image processing API services 

2938 For most of these API standards there exist standard language bindings so that 

2939 applications using different programming languages can access the same func- 

2940 tionality. 

2941 The choice of which graphics standard API to use will depend on a number of fac- 

2942 tors: application profile, overall system architecture, equipment available, exist- 

2943 ing application database interaction, system performance considerations, user 

2944 interface requirements, management policy, and other external factors. The aim 

2945 of producing a compatible set of graphics standards in GKS, GKS- 3 D, PHIGS, 

2946 PHIGS PLUS, etc. (described in the Standards subclause) is to allow that choice to 

2947 be made in the most flexible way. 

2948 4.7.4.4 External Environment Interface Services 

2949 The major categories of graphics services in the POSIX OSE EEI area include: 

2950 — Protocols 


Copyright © 1991 IEEE. All rights reserved. 

This is an unapproved IEEE Standards Draft, subject to change. 


4.7 Graphics Services 


133 



P1003.0/D13 


GUIDE TO THE POSIX OPEN SYSTEMS 


2951 — File Formats 

2952 — Device Drivers 

2953 The choice of which standard to use depends on a number of factors: application 

2954 profile, system architecture, equipment available, system performance considera- 

2955 tions, and other factors 

2956 4.7.4.5 Interapplication Software Entity Services 

2957 TBD 

2958 4.7.4.6 Graphics Resource Management Services 

2959 TBD 

2960 4.7.5 Standards, Specifications, and Gaps 

2961 There are several major standards existing in the computer graphics industry 

2962 today, that have been approved by National/International organizations such as 

2963 ANSI, ISO, and IEEE. There are also standards efforts going on in related areas 

2964 such as application data exchange. These official graphics standards are comple- 

2965 mented by de facto standards that have been accepted by the graphics industry at 

2966 large. This document provides a general explanation of these standards, their 

2967 specifications, and interrelationships. 

2968 4.7.5.1 Current Standards in the POSIX OSE 

2969 National/International 

2970 PHIGS — ISO 9592 Parts 1-3 

2971 Fortran Language Binding — ISO 9593-1 

2972 Ada Language Binding — ISO 9593-3 

2973 C Language Binding — DIS 9593-4 

2974 The Programmer’s Hierarchical Interactive Graphics Standard (PHIGS) 

2975 is a functional specification of the interface between an application pro- 

2976 gram and its graphics support system. It is an ANSI/ISO standard and 

2977 provides the following graphics functionality: 

2978 — A high degree of interactivity 

2979 — Multilevel, hierarchical structuring of graphics data 

2980 — Easy modification of graphics data and the relationships among the 

2981 data 

2982 — 3-D, as well as 2-D, graphical input and output 

2983 — Offline storage (and retrieval) of graphics data 
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2984 
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2985 _ 

2986 Figure 4-17 - POSIX OSE Graphics Service Reference Model Standards 


2987 PHIGS controls the definition, modification, and display of hierarchical 

2988 graphics data and specifies functional descriptions of systems capabili- 

2989 ties, including the definition of internal data structures, editing capabil- 

2990 ities, display operations, and device control functions. PHIGS manages 

2991 the organization and display of data in a centralized database, allowing 

2992 programmers to define and organize graphical data in a manner most 

2993 convenient to the application. Such a hierarchical approach is a big 

2994 benefit and is not available in GKS, another international standard. 

2995 Objects are defined in the PHIGS graphical database by a sequence of 

2996 elements, including output primitives, attributes, transformations, and 

2997 invocations of other object and object part definitions. These elements 

2998 are grouped into entities called structures. Structures may be related in 

2999 a number of ways, including geometrically, hierarchically, or according 

3000 to inherent properties or characteristics, as defined by an application. 


Copyright © 1991 IEEE. All rights reserved. 

This is an unapproved IEEE Standards Draft, subject to change. 


4.7 Graphics Services 


135 






P1003.0/D13 


GUIDE TO THE POSIX OPEN SYSTEMS 


3001 

3002 

3003 

3004 

3005 

3006 

3007 

3008 

3009 

3010 

3011 

3012 

3013 

3014 

3015 

3016 

3017 

3018 

3019 

3020 

3021 

3022 

3023 

3024 

3025 

3026 

3027 

3028 

3029 

3030 

3031 

3032 

3033 

3034 

3035 

3036 

3037 

3038 

3039 

3040 

3041 

3042 

3043 


PHIGS provides tools to use hierarchical data structures with minimal 
effort by the application programmer. Pictures constructed from 
geometric models often have a clearly evident structure. This structure 
can sometimes be easily seen in the repeated use of symbols, in the con¬ 
nections and geometric relationships between objects, or in the overall 
organization of a complex image. Even if the object’s structure is not 
evident, its underlying data organization may be quite rigorous, well 
defined, and well understood by the application. PHIGS supports both 
these cases by separating the definition of graphics data from the 
actions required to display them. 

The structured definition of graphics data inherently reduces repetition 
and connectivity problems. The repeated use of component objects and 
the relationships between them can automatically be made a part of an 
object’s definition. 

The structured definition of data allows images to share component 
objects, making it faster and easier for application programs to define 
and modify picture descriptions. Sharing component objects will also 
reduce storage requirements for graphics data. 

PHIGS permits rapid dynamic access to a centralized graphics database. 
This allows PHIGS to support interactive end user application programs 
and, depending on the capability of the hardware, realtime definition, 
and modification of graphics data. PHIGS is capable of performing 
three-dimensional modeling transformations, workstation transforma¬ 
tions, and viewing. It also handles two dimensions through a shorthand 
functionality of three dimensions. In workstation transformations, 
PHIGS provides another level of display control after the viewing opera¬ 
tion that can isolate a section of an image for pan and zoom operations. 

The National Institute of Standards and Technology (NIST) has 
developed a test system to help determine whether implementations of 
PHIGS conform to the specifications of the ANSI standard X3.144. The 
PHIGS Validation Test (PVT) suite consists of highly portable Fortran 
programs which examine test conditions and report the results. 

PHIGS PLUS — DIS 9592-4 

PHIGS Plus Lumiere Und Surfaces (PLUS) specifies a set of extensions 
to PHIGS that addresses some of the deficiencies in the graphics func¬ 
tionality provided by PHIGS. PHIGS does not include “higher level” 
primitives such as curves and surfaces, and techniques for lighting and 
shading. Recognizing this, an ad hoc working group was formed to pro¬ 
pose a set of extensions to PHIGS to enable these capabilities to be 
addressed in a standard manner, compatible with the overall philosophy 
of PHIGS. This set of proposed extensions was submitted to ISO and has 
since been developed into PHIGS PLUS. PHIGS PLUS enhances PHIGS by 
providing: 
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— Primitives for defining curves and surfaces 
— Lighting models 
— Shading of surfaces 
— Depth cueing 

— Color mapping and direct color specification 

PHIGS PLUS is not an international standard yet and is currently at the 
stage of committee draft. 

GKS — ISO 7942; FIPS 120 
Fortran Language Bindings — ISO 8651-1 
Pascal Language Bindings — ISO 8651-2 
Ada Language Bindings — DIS 8651-3 
C Language Bindings — DIS 8651-4 

GKS Information Bulletin 

The Graphical Kernel System (GKS) is a 2-D graphics system and pro¬ 
vides no support for 3-D. It is a 2-D graphics API that shields the pro¬ 
grammer from differences among various computers and graphic dev¬ 
ices. It allows for portability of graphics applications by standardizing 
the basic graphic functions and the method and syntax for accessing 
these functions. 

GKS is an ANSI, ISO standard and is widely used today. It has standard 
language bindings for Fortran and Pascal. Language bindings for C, 
Ada, and LISP are currently being worked on. 

GKS supports the grouping of logically related primitives such as lines, 
polygons, strings, and their attributes into collections called segments, 
which cannot be nested. 

GKS supports many graphical input and output devices such as 
black/white and color displays, printers, plotters, mice, data tablets, 
joysticks, and digitizers. 

GKS-3D — ISO 8805 

Fortran Language Bindings — DIS 8806-1 
Pascal Language Bindings — CD 8806-2 
Ada Language Bindings — DIS 8806-3 
C Language Bindings — DIS 8806-4 

Graphical Kernel System for Three Dimensions (GKS-3D) is an ISO 
standard and specifies extensions to GKS for defining and viewing 
three-dimensional wire-frame objects. In addition, the GKS input model 
has been extended to provide three-dimensional locator and stroke 
input. GKS-3D allows the operator to obtain information from three- 
dimensional input devices and to perform hidden line/hidden surface 
removal (HLHSR) at the workstation. It does not, however, provide 
specific functions for controlling rendering techniques such as light 
source, shading, texturing, and shadow computations that must be done 
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locally at the workstation. Conceptually, all workstations are three- 
dimensional in GKS-3D, which is made possible by shielding the 
hardware peculiarities as in GKS. 

CGI — DIS 9636 Parts 1-6 

Fortran Language Bindings — DIS 9638-1 

C Language Bindings — CD 9638-4 

The Computer Graphics Interface (CGI) specifies a standard functional 
and syntactical specification of the control and data exchange between 
device-independent graphics software and one or more device-dependent 
graphics device drivers. Unlike the graphics standards discussed ear¬ 
lier, CGI specifies an interface at the device-driver level, rather than at 
the application level. 

Unlike CGM, which only handles graphical output, CGI handles both 
input and output, which makes all devices appear as identical, virtual 
graphics devices. Therefore, this protocol is also known as the Virtual 
Device Interface (VDI). It provides a standard graphics escape mechan¬ 
ism to access nonstandard graphics device capabilities. CGI allows pro¬ 
grammers to write portable device-driver software that is independent 
of the physical graphics device characteristics. This makes the software 
portable and compatible with a wide variety of devices. 

CGM — ISO 8632 Parts 1-4 

The Computer Graphics Metafile for storage and transfer of picture 
description information (CGM) is a mechanism for retaining and/or tran¬ 
sporting graphics data and control information. This information con¬ 
tains a device-independent description of a picture at the level of the 
Computer Graphics Virtual Device Interface described above. It pro¬ 
vides a standard graphics escape mechanism to access nonstandard 
graphics device capabilities via the metafile. 

Pictures are described in CGM as a collection of elements of different 
kinds, representing, for example, primitives, attributes, and control 
information. It is multipart ANSI, ISO standard. Part 1 contains the 
semantics of all the elements. Parts 2, 3, and 4 contain the syntax of 
three different bindings of the standard, namely: character-coded, 
binary, and clear-text encodings. 

PHIGS Archive files — ISO 9592 Parts 2-3 

Parts 2 and 3 of the PHIGS standard define an archive file format for 
storage and transfer of PHIGS structures and structure network 
definitions from the CSS (Central Structure Store). Part 2 describes the 
file format and Part 3 a clear text encoding. This encoding is con¬ 
structed using the same techniques as used by CGM. 
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4.7.5.2 Emerging Standards in the POSIX OSE 

IPI —JTC1# 1002 

Image Processing and Interchange is a functional specification and 
several language bindings for an Application Programmer Interface to 
Imaging. The standard defines the data objects, primitive operations, 
and a reference model. The API supplies the basic building blocks upon 
which applications requiring imaging functionality can be built within 
conventional, distributed, and image oriented computing environments. 

The International Standard for Image Processing and Interchange 
includes three parts: 

Part 1 Common Imaging Architecture 

Part 2 Programmer’s Imaging Kernel (PIK) 

Part 3 Image Interchange Format 

PEX — PHIGS Extensions to X 

PEX is a network protocol extension to the X Window System. As many 
applications require 3-D graphics and other forms of input devices such 
as dials and button boxes, all of which are not supported by X, it became 
necessary to extend the X Protocol to include 3-D graphics. PHIGS was 
selected as the application program interface because of its acceptance 
as a 3-D standard, its high degree of input ability, and its powerful 
database editing capabilities. In 1988, the MIT X Consortium contracted 
to add 3-D and extended input extensions to the X protocol and the first 
release of PEX as a sample implementation (PEX-SI) was made in Janu¬ 
ary 1991 but is not yet available commercially. Using PEX, PHIGS 
workstations would be defined as X Windows. For the programmer, X, 
PHIGS, and PEX standards provide portability. 

Conformance Testing of Implementations of Graphics Standards —DIS 10641 

The existence of any standard brings up the question of how one can be 
sure whether a product claiming to conform to the standard does in fact 
conform. If this question is not addressed then the process of standardi¬ 
zation becomes pointless. 

The general approach to software validation is through testing. The 
method is to subject the software to a collection of test cases and observe 
the results. If the results are different from what is expected, the 
software does not conform to the specification. The ANSI X3H3.7 com¬ 
mittee is working on a standard that specifies the characteristics of 
standardized test sets for use in determining the conformance of imple¬ 
mentations of graphics standards. It will also provide guidance to func¬ 
tional standards developers concerning the content of their standards 
and the conformance rules within standards. 
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4.7.5.3 Gaps in Available Standards 

(1) Applications have different behaviors for similar functions which hinders 
user portability. By adopting a uniform approach 
(Graphics_Style_Guide) users can switch between applications without a 
lot of training. 

(2) Current existing standards allow a wide interpretation for implementors 
of the standards thus denying the applications useful controls. In order 
to achieve true portability in a distributed environment, applications will 
need control and deterministic functionality. 

(3) How window standard fits into CGRM 

(4) Current existing standards do not address solids. 

(5) The ability in a standard defined way to perform cut and paste between 
applications. 

(6) Current standards do not allow nonretained graphic methods to do light¬ 
ing and shading. 


4.7.6 OSE Cross-Category Services 

Not applicable. 


4.7.7 Related Standards 

IGES, NBSIR 86-3359 
See 4.5. 

X Window System Data Stream Definition Parts 1-4 
(Being worked on in ANSI X3H3.6) 

Part 1: Functional specification 

Part 2: Data Stream Encoding 

Part 3: KEYSYM Encoding 

Part 4: Mapping onto Open Systems Interconnection (OSI) Services 

The X Window System is a network based windowing and 2-D graphics 
system. It uses the client-server model. The client and server can 
reside on the same or different platforms. The client is an application 
program executing anywhere on the network and displaying on the 
screen. It does this by making calls to a library called Xlib to generate 
protocols. The X server is the software that accepts protocols sent by 
the client and processes them for display. It also accepts input from a 
mouse or keyboard for return to the application program. The X proto¬ 
col specifies the data stream encoding between the server and the 
clients. The X Protocol originally developed by the X Consortium at 
MIT, is being standardized by the ANSI X3H3.6 committee. The 
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encoding will provide a standard interface for applications running on 
both distributed and nondistributed environments having high-speed, 
reliable, network based communications. 

X Protocol is designed to work in a heterogeneous network environment. 
Below the X Protocol, any lower layer of network can be used, as long as 
it is bidirectional. Currently TCP/IP and DECnet are the two network 
protocols commonly supported in X servers. Part 4 of this standard 
specifies the mapping of X Windows onto the OSI Services. 

XLIB 


Xlib—C Language X Interface is the common component of X Windows 
and resides on all X-based systems. Although X is fundamentally 
defined by a network protocol, application programmers do not interface 
directly with the X Protocol. Instead, they interface to the X Protocol 
through Xlib. 

The X Window System uses the client-server model. The client is an 
application program executing anywhere on the network and displaying 
on the screen. It does this by making calls to Xlib to generate protocols. 
The X server is the software that accepts protocols sent by the client and 
processes them for display. 

From a graphics perspective, Xlib is a 2-D graphics library and provides 
graphics primitives like points, lines, and arcs. It has a Graphics Con¬ 
text (GC) to allow modification of graphics attributes such as line type, 
line width, color, and font type. The Xlib developed initially at MIT is in 
the Public Domain and is a de facto standard for windowing and 2-D 
graphics. It has been adopted by major computer vendors and industry 
groups. It is currently being considered for standardization by the IEEE 
P1201 committee. 

PostScript 

The PostScript language from Adobe Systems Incorporated is a simple 
interpretative programming language with powerful graphics capabili¬ 
ties that has become a de facto industry standard. It is a high-level, 
device independent language that is primarily used to describe the 
appearance of text, graphical shapes, and images on printed pages or 
screens. Programs written in this language may be used to communi¬ 
cate information from a composition system to a printing system. 
PostScript programs are created, transmitted, and interpreted in the 
form of source text and there is no compiled or encoded form of this 
language. 

SGML, ISO 8879: 1986 
See 4.5. 

IGES/PDES Organization (IPO) 

See 4.5. 
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ISO/IEC TC184/SC4 (STEP) 

See 4.5. 

ISO/IEC TC130 (Color Prepress) 

ISO/IEC JTC1/SC18 (Text and Office Systems 
ISO/IEC JTC1/SC29 (Multimedia Coding) 


4.7.8 Open Issues 

None. 


4.7.9 Performance and Capacity Specification Metrics 

Picture-Level Benchmark — (Developed by the GPC Committee) 

The Picture-Level Benchmark (PLB), developed by the GPC (Graphics 
Performance Characterization) Committee, is a software package that 
provides a standard method of measuring graphics display performance 
for different hardware platforms. The GPC Committee consists of the 
following member companies: DEC, DuPont Pixel Systems, Evans & 
Sutherland, HP/Apollo, IBM, Intel, Integraph, Megatek, Prime Com¬ 
puter, Silicon Graphics, Sun, and Tektronix. NCGA (National Computer 
Graphics Association) is the administrator for the GPC work. The PLB is 
a part of ongoing work by the GPC Committee to develop standardized 
methods of measuring graphics performance. 

The PLB was developed to clear the confusion regarding graphics perfor¬ 
mance measurement. Vectors or polygons per second can vary greatly 
according to size, orientation and other parameters. With the PLB, 
graphics display performance for the user’s specific application can be 
evaluated using the same methodology and measurement criteria for 
different hardware systems. This allows “apple-to-apple” comparisons 
of graphics display performance. 
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3271 4.8 Character-Based User Interface Services 

3272 Responsibility: Charles Severance 

3273 4.8.1 Overview and Rationale 

3274 This clause describes the system services that are related to character-based ter- 

3275 minals. It describes both the application program interfaces to character-based 

3276 terminals and also the look and feel of the interaction between the user and the 

3277 user interface equipment. 

3278 This clause is one portion of the User Interface API and EEI as described in Sec- 

3279 tion 3. 

3280 4.8.2 Scope 

3281 The scope of this clause is limited to the services and standards required to sup- 

3282 port character (non-bitmapped) terminals. 

3283 4.8.3 Reference Model 

3284 This subclause identifies the entities and interfaces specific to the character-based 

3285 terminal services of an OSE. 

3286 As illustrated in Figure 4-18, the components of character-based interfaces are 

3287 broken into two groups: those specifications that impact the application program- 

3288 ming interface and those that impact the external user interface. 

3289 This reference model is consistent with and expands on the reference model in 

3290 Section 3. 

3291 4.8.4 Service Requirements 

3292 The fundamental service requirements for character-based terminals are to allow 

3293 applications to be written that make use of the features of a wide variety of termi- 

3294 nals using a single terminal-independent interface. The look and feel of user 

3295 interactions should be similar between applications to make moving between 

3296 applications as simple as possible. 

3297 4.8.4.1 Application Program Interface Services 

3298 The service requirements at the Application Program interface are as follows: 

3299 — Ability to support a wide variety of character-based terminals using a sin- 

3300 gle terminal-independent API. 

3301 — Ability to support a wide variety of block mode terminals using a single 

3302 terminal-independent API. 
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3304 _ 

3305 Figure 4-18 - Character-based Terminal Reference Model 

3306 — Ability to support all types of terminals using a forms-based API. 

3307 These interfaces should be complete enough to allow a wide range of applications 

3308 to be implemented using the interfaces. 

3309 4.8.4.2 External Environment Interface Services 

3310 The look and feel of user interactions with applications should be standardized to 

3311 make moving between applications as simple as possible. The areas that require 

3312 standardization are: 

3313 — Placement of text on the screen 

3314 — Style of selecting commands 

3315 — Ways of using online help 

3316 — Ways to do common functions such as page forward and page backwards. 

3317 These interactions will differ slightly between different types of terminals because 

3318 of limitations of the terminals. 
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3319 4.8.4.3 Related Service Requirements 

3320 To be provided. 

3321 4.8.5 Standards, Specifications, and Gaps 

3322 4.8.5.1 Current Standards in the POSIX OSE 

3323 None. 

3324 4.8.5.2 Emerging Standards in the POSIX OSE 

3325 FIMS 

3326 ANSI CODASYL. Working draft available for Forms Interface Management Sys- 

3327 tern (FIMS), which covers the interface between a programming language and any 

3328 form-filling application on a computer or terminal screen. 

3329 This specification addresses some of the services requirements for a forms-based 

3330 user interface. 

3331 CRS: Parts ofPOSIX.2 might belong here. 

3332 4.8.5.3 Gaps in Available Standards 

3333 4.8.5.3.1 Standards/Specifications Outside the POSIX OSE 

3334 4.8.5.3.1.1 Government/Legal Standards 

3335 None. 

3336 4.8.5.3.1.2 De Facto Standards 

3337 Curses 

3338 Curses is a set of subroutines that provide a terminal-independent interface to 

3339 applications. Many different types of character-based terminals are supported. 

3340 Curses lacks complete support for flexible user input. 

3341 This standard satisfies some of the service requirements for character mode ter- 

3342 minals. 

3343 SAA 

3344 SAA is an interface specification to a large class of block mode terminals. This 

3345 standard satisfies some of the service requirements for controlling block mode ter- 

3346 minals. 
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4.8.6 OSE Cross-Category Services 


4.8.6.1 Security 

4.8.6.2 Administration 

It is important to allow the system management personnel to configure the sys¬ 
tem to designate where each terminal is connected. Also needed is the ability to 
add support for new terminals without affecting the application interface. 

4.8.6.3 Configuration Management 

4.8.6.4 Fault Management 

4.8.6.5 Performance 

4.8.6.6 Accounting 

4.8.6.7 Training 

4.8.6.8 Systems Integration Interface Requirements 

None. 


4.8.7 Related Standards 

None. 


4.8.8 Open Issues 

None. 
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3364 4.9 User Command Interface Services 

3365 Responsibility: Wendy Rauch 

3366 HLJ: Wendy has provided a full clause replacement for Draft 13; it is not further D 

3367 diff marked. D 

3368 4.9.1 Rationale and Overview 

3369 Although system-level services are necessary for application portability and 

3370 interoperability, they are insufficient for many users’ system needs. To maximize 

3371 portability, users also require the commands, command interpreter (shell), corn- 

3372 pilers, editors, and other utilities that have been traditionally associated with 

3373 many operating systems. These command interface services facilitate a successful 

3374 port and help users to manage and maintain applications and to solve problems 

3375 on an ad hoc basis. The standardization of these utilities allows users and pro- 

3376 grammers to move from platform to platform without having to relearn the corn- 

3377 mand interface for each application platform. 

3378 4.9.2 Scope 

3379 This clause describes how a user interacts with an application platform by execut- 

3380 ing general purpose commands. This command interface is also available to 

3381 applications so that applications also can execute commands. A standardized 

3382 command interface provides a consistent, interactive environment across plat- 

3383 forms for users and programmers. 

3384 Commands that are outside the scope of this clause are: 

3385 — System administration and installation commands 

3386 — Text formatting programs 

3387 — Database commands 

3388 — Networking and communications commands 

3389 — Graphical user interfaces 

3390 Networking commands and graphical user interfaces are described in other 

3391 clauses of the POSIX Open Systems Environment Guide. 

3392 4.9.3 Reference Model 

3393 The use of the command interface services presented in this clause is consistent 

3394 with the reference model in Section 3. The POSIX OSE reference model for the 

3395 command interface also is consistent with typical implementations for user corn- 

3396 mand languages in traditional UNIX-based systems. 

3397 As Figure 4-19 shows, the command interface is available both to users (through 

3398 the External Environment Interface) and to applications (through the Application 
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3400 _ 

3401 Figure 4-19 - POSIX OSE Reference Model for Command Interfaces 

3402 Programming Interface). Any operating system implementation can reside under- 

3403 neath the APIs and EEIs. 

3404 The API and EEI command interfaces provide access to a software component 

3405 (known as a command interpreter or shell) that interprets the commands issued 

3406 by either the user or the application. The command interpreter acts as an 

3407 intermediary between the command API and EEI and the base application 

3408 platform’s system-level services. The command interpreter reads the commands 

3409 entered and parses them. Depending on the type of command (e.g., utility or 

3410 built-in shell command), the command interpreter either executes the command 

3411 for the user or application, using the base application platform’s system-level ser- 

3412 vices, or it calls on the system-level services to create a new process which exe- 

3413 cutes the command. 

3414 None of the methods of executing commands have an impact on the API or EEI 

3415 specifications. 

3416 The commands interfaces may be available to users and applications either locally 

3417 or remotely. Remote invocation of a system’s command interfaces is provided 

3418 through networking and data interchange capabilities. These are described in 4.3 

3419 and 4.5. Alternatively, remote access to a system’s command interfaces may be 

3420 available through certain interapplication services. 
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4.9.4 Service Requirements 

There are three major aspects of command interface services that must be 
addressed for practical support of multivendor application portability and system 
interoperability. The first aspect consists of the basic functionality and interfaces 
provided for generally usefulness. The second aspect of command interface ser¬ 
vices concerns the ability to move applications, such as script files, between plat¬ 
forms. The third aspect concerns user portability so that the same user interface 
is available on different platforms. 

Since most command interfaces are available at the API and EEI, the service 
requirements for the API and the EEI are very similar. This clause, therefore, 
discusses primarily the EEI command interface requirements. The API service 
subclause discusses only the additional service requirements for applications. 

4.9.4.1 External Environment Interface Services 

Users need a number of capabilities in order to work on a system. On a tradi¬ 
tional system, these are implemented by providing interactive commands entered 
via a keyboard. However, as graphical user interfaces evolve, these commands 
may also be implemented by clicking on a mouse in a particular area of the 
screen, by a “touchie-feelie” screen, a tablet, or other input device. 

The major services at the EEI provide the following abilities: 

— Capture the output of a command or application into a file 

— Redirect the input for a command from a file 

— Direct the output of a command to be used as the input to another com¬ 
mand 

— Execute applications 

— Get online help for commands or applications 

— Manipulate file contents: 

• Cutting 

• Pasting 

• Concatenating 

• Converting 

• Sorting 

• Reformatting 

• Comparing 

• Searching for regular expression 

— Edit files 
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• Interactive editors 

• Batch or “stream” editors 

— Display files 

• Pausing when necessary 

• Display only selected ranges of files 

— Manipulate files 

• Create 

• Delete 

• Rename 

• Move 

• Copy 

— Print files 

— Perform network functions 

• File transfer 

• Remote execution of commands 

• Remote file printing 

— Manipulate and display directories 

• Create 

• Delete 

• Display 

• Destroy (Delete a directory and all its subdirectories and files) 

— Control file and directory permissions 

— Communicate with other users 

• Electronic mail 

• Online interaction where two or more users communicate with each 
other simultaneously 

— Control the application execution environment 

• Execute applications in the background 

• Abort applications running in the foreground or background 

• Suspend an application 

• Move an application running in foreground mode to the background 

— Schedule commands for periodic execution 
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— Control the users’ input equipment, such as a terminal or graphical user 
interface 

— Manage local environment and configuration information 

— Query local environment and configuration data 

— Configure an environment for an international locale. 

4.9.4.2 Application Program Interface Services 

In a command API, the output syntax of the commands and command responses 
(such as error messages) need to be standardized, in addition to the calling 
sequence and allowable inputs. Such standardization is necessary to allow appli¬ 
cations executing a command to reliably parse the output of that command. 

The API should be able to access all of the services available to the user at the 
EEI. The additional service requirements for the API are as follows; 

— Ability to provide the input to the command and access the output of the 
command when necessary 

— Ability for the application to detect and correct errors as the command is 
executed 

— Ability to abort or suspend the command as it is executing. 

It is also important to have the ability to create script files which are combina¬ 
tions of commands. The scripting language developed for this purpose is an appli¬ 
cation development language. The scripting language has the following require¬ 
ments: 

— Conditional execution primitives 

— Repeated execution primitives 

— Ability to display output 

— Ability to prompt the user for input 

— Ability to execute commands and obtain error information. 

The services and standards for the scripting language are described in this clause, 
rather than in the Languages clause 4.1, because it is so closely related to the 
command interface. 

4.9.4.3 Interapplication Entity Services 

These services enable remote users and applications to access and execute a 
system’s command interfaces as if they were directly connected to that system. 
The major categories of interapplication entity services include the following: 

— Login and use hosts on a network as if the users logging-in were directly 
connected to the local terminal 
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3523 — Remotely execute a system’s shell commands as if the user were directly 

3524 connected to a local terminal 

3525 — Copy files between hosts without going through a network file transfer pro- 

3526 gram 

3527 — Find out who else is logged into the machines on a local-area network 

3528 — Query the status and uptime of all machines on a local-area network. 

3529 4.9.5 Standards, Specifications, and Gaps 

3530 There are currently no formal standards for command interfaces. There are, how- 

3531 ever, several command-interface standards-development activities underway. In 

3532 addition, there are several consortia-defined specifications and de facto 

3533 specification standards for commands, shell, and utilities services and interfaces. 

3534 Table 4-10 summarizes the shell and utilities standards and specifications and 

3535 work in progress. 


3536 Table 4-10 - Shell and Utilities Standards Activities 

3537 _ 


3538 

Service 

Specification 

Subclause 

3539 

Shell and Utilities 

IEEE POSIX.2 {ref\ 

4.9.5.? 

3540 

User Portability Extension (UPE) 

IEEE POSIX.2a {re/} 

4.9.5.? 

3541 

Shell, Utilities, and UPE 

X/Open XPG 4.9.5.? 


3542 


OSF OSF/1 


3543 


System V: 1989 SVID 


3544 


Berkeley BSD 4.x UNIX 


3545 





3546 4.9.5.1 Current Standards 

3547 4.9.5.1.1 International and National Standards 

3548 There are no currently completed or approved international or national standards 

3549 for commands and utilities. 

3550 4.9.5.2 Emerging Standards 

3551 4.9.5.2.1 International and Other Formal Standards 

3552 When completed, the IEEE POSIX.2 {ref\ standard will define a source code inter- 

3553 face to command interpretation or shell services and common utility programs for 

3554 application programs. These services and programs are complementary to those 

3555 specified by POSIX. 1 {2}. 
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3556 The IEEE POSIX.2a { ref) User Portability Extension will supplement POSIX.2 [ref] 

3557 by extending the specifications to promote the portability of users and program- 

3558 mers, in addition to applications, across conforming systems. Toward this end, 

3559 the POSIX.2a { ref) specifications expand the number and type of utilities specified, 

3560 and enhance the features of a number of POSIX.2-specified utilities, to provide a 

3561 consistent interactive environment. The consistent interactive environment does 

3562 not include emerging technologies such as graphical user interfaces, which are 

3563 under development by different standards groups. 

3564 Parts of POSIX.2 { ref) go beyond the current service requirements and include a 

3565 number of software development and debugging commands and utilities services. 

3566 These are included in the POSIX.2 specification because of the traditional develop- 

3567 ment orientation of UNIX systems. These software development and debugging 

3568 services are not included in this clause because this clause includes more general 

3569 and universal services, such as copying a file and reading a directory. 

3570 Although the POSIX.2 { ref] and POSIX.2a {refs specifications are still in draft 

3571 stages, they are relatively complete, and portions of the emerging standard are 

3572 believed to be mature and stable. 

3573 When the commands, shell, and utilities specifications are completed and 

3574 approved, the resulting IEEE POSIX.2 {re/} and POSIX.2a {re/} standards will be 

3575 submitted to ISO/IEC JTC 1 for adoption as international standards. At that time, 

3576 POSIX.2 and POSIX.2a will be combined into a single integrated international 

3577 standard (ISO/IEC 9945-2). 

3578 4.9.5.3 Gaps in Available Standards 

3579 There are no formal interapplication standards that address the remote access 

3580 and execution of a system’s command interfaces. The Berkeley BSD UNIX de facto 

3581 standard addresses all these service requirements, however. 

3582 4.9.5.3.1 Public Specifications 

3583 Public specifications that include the POSIX.2 [ref] and POSIX.2a {refs, and go 

3584 beyond these standards to also include the traditional UNIX-based command 

3585 interfaces for software development, system administration, the UUCP (UNIX-to- 

3586 UNIX Communications Protocol) utilities, and parts of the POSIX.4 realtime exten- 

3587 sions are available from a number of organizations. These include: 

3588 — X/Open’s XPG3 specifications, Volume 1 and part of Volume 3 

3589 — OSF’s OSF/1 Application Environment Specifications (AES), software docu- 

3590 mentation, and software 

3591 — University of California at Berkeley BSD UNIX 

3592 — AT&T System V Interface Definition (SVID) and System V UNIX. 
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3593 4.9.6 POSIX OSE Cross-Category Services 

3594 4.9.6.1 Internationalization 

3595 The ANSI C, IEEE POSIX. 1, and IEEE POSIX.2 specifications contain limited capa- 

3596 bilities for obtaining and defining locale-specific information. In addition, some of 

3597 the utilities described in the POSIX.2 specifications contain requirements for 

3598 standardized multilingual and multicultural support (e.g., localization require- 

3599 ments such as date formats and collation sequences, and support for international 

3600 character sets). 

3601 4.9.7 Related Standards 

3602 Several standards activities are in progress to address additional commands 

3603 interfaces that are traditionally included in UNIX and UNIX-like systems. The fol- 

3604 lowing standards are examples: 

3605 — IEEE 1003.4 Realtime Extensions for POSIX 

3606 — IEEE 1003.7 POSIX System Administration Extensions 

3607 — IEEE 1003.18 Platform Environment Profile (PEP) standard, which 

3608 identifies and combines the standards dealing with POSIX. 1, POSIX.2, 

3609 POSIX.2a, and the related standards 

3610 4.9.8 Open Issues 

3611 Conformance Testing 

3612 Command interface standards must address conformance testing. Although the 

3613 POSIX.2 standard is still in a draft stage, work has already begun in the IEEE 

3614 1003.3.2 Conformance Test Methods Group to define test assertions for the 

3615 POSIX.2 standard. 

3616 UUCP 

3617 The UUCP (UNIX-to-UNIX Copy Protocol) services and commands, for electronic 

3618 mail and file copying, which are traditionally included in UNIX and UNIX-like sys- 

3619 terns are not addressed by any standards effort. Among other reasons, UUCP is 

3620 not currently being addressed because of the inability of the POSIX groups to 

3621 decide whether the UUCP services and commands should be standardized in the 

3622 POSIX.2 Group (since UUCP is a traditional UNIX service with traditional corn- 

3623 mand interfaces) or in the networking groups (since UUCP is an electronic mail 

3624 and file copying facility that works on networks). 
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3625 4.10 Transaction Processing Services d 

3626 Responsibility: Bob Gambrel 

3627 Based on input created by Carl Hall of P1003.ll, with contributions from Jeremy 

3628 Denny, John Penny, Patrick Prange, and Jeff DeMent Revised in Draft 13 with D 

3629 input from Dorm Fulton of P1003.11. D 

3630 4.10.1 Overview and Rationale 


3631 The database management clause (see 4.4) described some transaction processing d 

3632 service requirements (specific to databases). This clause describes the complete d 

3633 set of transaction processing services from the application software point of view. D 

3634 Note that transaction processing services have long been been regarded, vari- d 

3635 ously, to be within the domain of databases or within the domain of operating sys- D 

3636 terns, and more recently within the domain of interconnect. These services are D 

3637 more broadly applicable and so are treated here as a separate clause. d 


3638 Transactions (“units of work”) have boundaries (start points and end points) that D 

3639 are determined by the action of the transaction application program. The tran- D 

3640 saction application program can request to either commit or rollback the work D 

3641 done in the transaction when it identifies the end point. The system will complete D 

3642 a commit operation only if all operations performed during the transaction can 

3643 complete successfully. Otherwise the system will abort the transaction (rollback d 

3644 the work done by it) and notify the transaction application program of this action. D 

3645 The following is quoted with a few editorial changes from ISO/IEC DP 10026-1 

3646 {re/}, the ISO Distributed Transaction Processing standard draft: 

3647 A transaction is characterized by four properties: atomicity, con- 

3648 sistency, isolation, and durability. These are the ACID properties. 

3649 Atomicity implies that the operations of a unit of work are either all 

3650 performed, or none of them are performed. 

3651 Consistency implies that the operations of a unit of work, if per- 

3652 formed at all, are performed accurately, correctly, and with validity, 

3653 with respect to application semantics. 

3654 Isolation implies that the partial results of a unit of work are not 

3655 accessible, except by operations which are part of the unit of work. 

3656 Isolation also implies that units of work which share bound data are 

3657 serializable. 

3658 Durability implies that all the effects of a completed unit of work are 

3659 not altered by any sort of failure. 

D 
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3660 4.10.2 Scope 

3661 This clause deals with the transaction processing services needed for a large d 

3662 number of styles of transaction processing including the following: D 

3663 — Transactional access to a single database manager on a single machine d 

3664 — Transaction access to nondatabase “resource managers” (such as the d 

3665 software managing the cash in an automatic teller machine D 

3666 — Distributed Databases—databases spanning multiple machines, but d 

3667 accessed by application programs as if just a single database d 

3668 — Online Transaction Processing (OLTP)—the scheduling of “transaction pro- d 

3669 grams” based on terminal input with consolidated recovery of the database D 

3670 updates and the terminal messages d 

3671 — Distributed Transaction Processing (DTP)—different machines running D 

3672 multiple application programs with multiple databases, using a D 

3673 client/server or conversational application-to-application communications D 

3674 paradigm d 

3675 Note that Transaction Processing Services are used in all of the above situations, d 

3676 and others too. d 

3677 Finally, it should be noted that “transactions” are not really “messages,” but D 

3678 rather “units of work” that may encompass multiple messages. Furthermore, D 

3679 while traditionally, “transaction processing” has usually been synonymous with D 

3680 “OLTP” where so-called “immediate transactions” are the norm, other types of D 

3681 transactions are also covered: “batch transactions” (where the work is done in the D 

3682 “background”) and “deferred transactions” where there may be a time dependence d 

3683 on the transaction, such as a fixed start time. D 

3684 This clause addresses the current work in progress in groups such as ISO and oth- 

3685 ers. 

3686 4.10.3 Reference Model 

3687 This subclause addresses the conventional Transaction Processing Reference 

3688 Model, the POSIX OSE Reference Model (incorporating transaction processing con- D 

3689 siderations), and other important real world considerations introduced by Tran- D 

3690 saction Processing. d 

3691 4.10.3.1 Conventional Transaction Processing Reference Model D 

3692 A model for transaction processing is developed here to complement the POSIX 

3693 system model. Current work in progress by the POSIX.il Transaction Processing 

3694 Working Group and other groups such as ISO/IEC JTC 1/SC21 Open Systems 

3695 Interconnection—Distributed Transaction Processing may result in a Transaction 

3696 Processing Reference Model more suitable than the one developed here. At that 

3697 time, such a model will be referenced and incorporated into the POSIX OSE refer- 

3698 ence model. Until that time, the current model will be used as a convenient 
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3699 means for describing the services needed in this domain. 

3700 While transaction processing services have usually been thought of as applying to d 

3701 databases, the applicability goes further. Nonetheless, the description given here d 

3702 of the transaction processing model shows how the transaction processing pro- D 

3703 gram can view the transaction services as an extension of the the Database view d 

3704 of the POSIX OSE reference model as shown in Figure 4-11. From the transaction 

3705 application program point of view, a transaction processing system has additional 

3706 capabilities that go beyond those provided by database systems. These services to 

3707 the transaction application program are provided at an API that is called the D 

3708 Transaction Manager API. (See Figure 4-20.) For convenience in discussing the D 

3709 model, the provider of those services is called the Transaction Manager (TM). 

3710 _ 



TM/TPRM 

Sll 


3711 _ 

3712 Figure 4-20 - The Conventional Transaction Processing Model D 

3713 The transaction application program requests services provided by the TP D 

3714 resource manager (e.g., a database manager) via the TP resource manager API. D 

3715 The transaction manager API and the TP resource manager API are called the D 

3716 transaction services API and provide all the services needed by transaction appli- D 

3717 cation programs. D 

3718 The ACID properties are maintained for each managed resource by a TP Resource 


3719 Manager (TPRM), coordinated by a Transaction Manager. The interface between 

3720 the TP Resource Manager and the Transaction Manager will be called the Tran- 

3721 saction Manager / TP Resource Manager SII (TM / TPRM SII). 

3722 The ACID properties can be applied not only to resources such as databases, but 

3723 also to other resources that might not be obvious. For instance, a transaction that 

3724 dispenses cash may wait until the cash dispensing machine has signaled comple- 

3725 tion before considering the transaction complete and updating involved accounts. 

3726 This illustration also shows the limits of transaction processing resource manage- D 

3727 ment. The machine could signal completion, but a mechanical problem could 
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3728 prevent the cash from being dispensed correctly, undetected by the system. 

3729 Besides database TPRMs and miscellaneous nondatabase TPRMs, a third class of D 

3730 of TPRMs exist: Communications TPRMs (cTPRM). Services provided by cTPRMs D 

3731 are used when two cooperating transaction application programs need to com- D 

3732 municate with each other in the context of the same transaction. At least two D 

3733 communications paradigms have been identified as beneficial to cooperating tran- D 

3734 saction applications programs: client/server (RPC, single request/response) and D 

3735 conversational (peer-to-peer, dialog). D 

3736 4.10.3.2 POSIX OSE Reference Model (with Transaction Processing) 

3737 The conventional transaction processing model is shown integrated into the D 

3738 POSIX OSE Reference Model in Figure 4-21. Because the POSIX OSE Reference 

3739 Model does not address System Integration Interfaces (SIIs) per se, they are not 

3740 shown in the integrated model. What is shown are the transaction processing ser- D 

3741 vices APIs and EEIs. D 


3742 4.10.3.3 Real World Considerations 

3743 The POSIX OSE Reference Model does not provide for a way to expose the details 

3744 of the Application Platform. In the Transaction Processing world, as shown in the 

3745 conventional Transaction Processing Reference Model (see 4.10.3.1), the existence 

3746 of Transaction Managers and multiple TP Resource Managers connected by the D 

3747 TM/TPRM SII is important. One way to think about the real world implications of D 

3748 this is that TP Resource Managers and the Transaction Managers could both be d 

3749 implemented in the Application Platform as separate entities, connected to each d 

3750 other by the TM/TPRM SII. This does not, however, imply that the two must be D 

3751 implemented as separate entities, though there are advantages to the user if they d 

3752 are separate. d 

3753 4.10.4 Service Requirements 

3754 Services provided via the Transaction Processing Services API are described in d 

3755 4.10.4.1. Services to enable the distribution of transaction processing are 

3756 described in 4.10.4.2. General services, mostly performing administrative func- 

3757 tions, are described in 4.10.4.4. Services provided across the TM/TPRM SII are D 

3758 briefly described in 4.10.4.5. D 

3759 4.10.4.1 Application Program Interface Services 

3760 This subclause describes the major categories of services available at the POSIX d 

3761 API. D 

3762 The Transaction Services API provides various services to the application pro- d 

3763 grammer: D 
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3764 



3765 _ 

3766 Figure 4-21 - The POSIX OSE Transaction Processing Reference Model D 

3767 Transaction Demarcation D 

3768 Ability to indicate the start of a transaction. D 

3769 Ability to indicate a transaction has ended successfully (commit) or unsuc- D 

3770 cessfully (rollback). d 


3771 Ability to indicate the beginning and ending of nested “subtransactions” D 

3772 whose commitment is independent of the “parent transaction”. (Nested D 

3773 within a parent transaction can be multiple subtransactions. Subtransac- D 

3774 tions are independent of each other, and whether subtransactions commit D 


3775 or not does not affect the commitment of the parent.) D 

3776 The ability to suspend and resume transaction mode (to do work which is D 

3777 not be committed or rolled back when the transaction is completed). This D 

3778 can be thought of as nesting nontransaction work within a transaction. D 

3779 Ability to explicitly include or exclude items from a transaction. RJG: D 

3780 PO—this was yours. Isn’t this really the above nesting item ? D 


Copyright © 1991 IEEE. All rights reserved. 

This is an unapproved IEEE Standards Draft, subject to change. 


4.10 Transaction Processing Services 


159 






P1003.0/D13 


GUIDE TO THE POSIX OPEN SYSTEMS 


3781 Communications Between Transaction Application Programs D 

3782 Ability to call another transaction application program (possibly remote) D 

3783 within the context of a transaction. D 

3784 Ability to open a dialog and send and receive “messages” to and from D 

3785 another transaction application program (possibly remote) within the con- D 

3786 text of a transaction. d 


3787 NOTE: The above services provide “Distributed Transaction Processing.” The above ser- D 

3788 vices often go by shorthand names such as “Remote Procedure Call (RPC),” “Single D 

3789 Request/Response,” or “Client/Server,” in the first case, and “Dialogs,” “Conversations,” or D 


3790 “Peer-to-Peer” in the second case. D 

3791 Terminal Communications D 

3792 Ability to send and receive messages to and from terminals within the con- D 

3793 text of a transaction (i.e., messages sent to terminals are not to be actually d 

3794 delivered unless the transaction commits. D 

3795 Transaction Program Scheduling D 

3796 Ability to cause to be started another transaction application program out- D 

3797 side of the context of this transaction. Involved here are two transactions: D 

3798 one starts the other. The actual scheduling of the second transaction can D 

3799 be dependent on the completion or not of the original transaction. D 

3800 Transaction Message Queuing d 

3801 Ability to define a “message” (based, possibly, on screen input from the end D 

3802 user) that, from the application point of view, precisely defines a unit of D 

3803 work to be done by this transaction or another transaction. D 

3804 Ability to “send” a message to another transaction application program. D 

3805 Ability to retrieve the next message (and then act upon it) D 

3806 Ability to prioritize and associate start times with messages D 

3807 NOTE: The actual handling of messages can be dependent on the completion or not of the D 

3808 original transaction. D 

3809 NOTE: Several of the above services are similar to but semantically different from similar sounding D 

3810 services in other clauses of this section. They are listed here because they are “transactional”; i.e., D 

3811 the concept of a transaction and the ACID properties are provided by these services. D 


3812 TP Resource Managers provide services usable by the transaction application pro- 

3813 gram and are made visible by the TP Resource Manager API. An example of this 

3814 is the Database API covered earlier in this document. 

3815 NOTE: TP Resource Managers, in general, “protect” a critical resource. Databases are good exam- 

3816 pies of TP resource managers where the resource actually being protected is the data, for example, of 

3817 an enterprise. Often the data of an enterprise reflects the amount of a real resource such as cash 

3818 holdings. In this case a tangible resource is indirectly protected by a TP resource manager. The 

3819 importance to the enterprise in insuring that the data (quantifying money) is accurate, should be 

3820 obvious. Other TP resource managers, on the other hand, could protect an actual, tangible resource. 

3821 An example of such a TP resource manager is the program that controls the cash drawer of an 

3822 automated teller machine. The resource protected is the cash in the drawer. The actual application 
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3823 

3824 

3825 

3826 

3827 

3828 

3829 

3830 

3831 

3832 

3833 


3834 

3835 

3836 

3837 

3838 

3839 

3840 

3841 

3842 

3843 

3844 

3845 

3846 

3847 

3848 

3849 

3850 

3851 

3852 

3853 

3854 

3855 

3856 

3857 

3858 


program interface of the TP resource manager protecting that resource could include the ability to 
reduce the amount of money in the drawer (by pushing it out of the machine). A transaction applica¬ 
tion program using two TP resource managers (a conventional database manager that keeps track of 
the balance in accounts, and the teller machine’s cash drawer TP resource manager) would want to 
insure that the two TP resource managers decrement both the cash and the balance of the correct 
account in the context of a single transaction (i.e., with the ACID properties.) 

The TP Resource Manager API, then, generally provides the following services: 

(1) Ability to increment or decrement a valuable resource by a certain amount. 

(2) Ability to determine the amount of a valuable resource that remains. 

Specific capabilities for the very wide variety of specific TP resource managers, cannot, of course, be 
documented here. 


D 


4.10.4.2 External Environment Interface Services 

When two or more machines are involved in the same transaction, the following D 
service is required: d 

— The ability for two application platforms to interoperate with each other D 
(pass along global transaction identifiers, participate with each other in 
commitment process, participate with each other in recovery). 

4.10.4.3 Interapplication Software Entity Services 

4.10.4.4 OLTP Resource Management Services 


The services listed in this subclause are not provided by application program 
interfaces or external environment interfaces. D 

— Management Services — Ability to control the operation of the transaction D 
processing services, including the ability to assign dispatching priorities to D 
individual transaction application programs. D 


— Monitoring Services — Ability to collect data on resource utilization for 
purposes such as performance analysis and accounting (data on utilization 

of the transaction processing services resources: processes, connection d 

pools, ...). D 

— Modeling Services — Ability to predict the system resources needed to pro- D 

cess a given transaction processing workload. D 

— Directory/Namespace Services — Ability to map names to addresses. 

— Recovery/Restart Services — Ability to recover and restart transactions D 

involving one or more transaction application programs using one or more D 
TP Resource Managers. D 

— Test Services — Ability to automatically generate tests for workload simu- d 

lation, etc. d 
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3859 

3860 

3861 

3862 

3863 

3864 

3865 

3866 

3867 

3868 

3869 

3870 

3871 

3872 

3873 

3874 

3875 

3876 

3877 

3878 

3879 

3880 

3881 

3882 

3883 


3884 

3885 

3886 

3887 

3888 

3889 

3890 

3891 

3892 

3893 

3894 


— System Configuration Services — Ability to replace or add transaction d 
application programs without the need to shut down the execution environ- D 
ment. D 

4.10.4.5 Services Provided at the TM/TPRM SII 


HLJ: RJG asked for this to he an “informative subclause.” The only way to do that D 
is to make it a NOTE: D 

NOTE: For application portability it is not required that the application platform actually consist of D 

Transaction Managers and TP Resource Managers, but in the new age of Open Systems, there are D 

clear advantages in doing so. Two advantages seem obvious: the ability to “mix and match” Tran- D 

saction Managers and TP Resource Managers from different vendors; and the ability of a user to con- D 


struct his/her own TP Resource Manager to manage particular critical resources. A market has D 
already developed for “plug compatible” TMs and TPRMs. All TPRMs at this printing are Database D 
type TPRMs. It is expected that a market will also develop for Communications type TPRMs. It is D 
not at all clear that the industry will develop other types of widely applicable TPRMs, thus forcing D 
users to develop their own. Users could use the interface described here to do such development D 
work. D 

This NOTE very briefly describes the services that should be provided at such an interface. D 

The TM/TPRM interface must provide the ability of TMs and TPRMs to: register with each other; D 
obtain recovery status information; pass along transaction identifier information; rollback, prepare D 
to commit, and commit the transaction. The interface must provide for the needs of the full range of D 
transaction processing including distributed transaction processing with multiple TPRMs. D 

Finally it should be noted that the industry recognizes the need for standardization of components D 
as well as the standardization of portability and interoperability. At least one industry group is D 
standardizing and several vendors are implementing products utilizing an interface as described D 
here. D 


4.10.5 Standards, Specifications, and Gaps 

There are currently three transaction processing standards development activi¬ 
ties, either completed or in the draft stage. Table 4-11 summarizes the service 
requirements provided by the various standards. 

Table 4-12 summarizes the applicability of the various standards to the various 
programming languages supported by the POSIX Open System Environment. 

4.10.5.1 Current Standards in the POSIX OSE 

4.10.5.1.1 International Standards 

None. 

4.10.5.1.2 Regional Standards 

None. 


D 


D 
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3895 Table 4-11 - Transaction Processing Standards Activities 

3896 _ 


3897 

Service 

Specification 

Subclause 


3898 

Transaction Demarcation 

Emerging (P1003.ll {ref]) 

4.10.5.? 

D 

3899 

Communications 

Gap 

4.10.5.? 

D 

3900 

Terminal Communications 

Gap 

4.10.5.? 

D 

3901 

Program Scheduling 

Gap 

4.10.5.? 

D 

3902 

Message Queuing 

Gap 

4.10.5.? 

D 

3903 

EEI Services 

Emerging (ISO/IEC DIS 10026-1,2,3 [ref]) 

4.10.5.? 


3904 

Management 

Gap 

4.10.5.? 

D 

3905 

Monitoring 

Gap 

4.10.5.? 

D 

3906 

Modeling 

Gap 

4.10.5.? 

D 

3907 

Directory/N amespace 

Gap 

4.10.5.? 

D 

3908 

Recovery/Restart 

Gap 

4.10.5.? 

D 

3909 

Test 

Gap 

4.10.5.? 

D 

3910 

System Configuration 

Gap 

4.10.5.? 

D 

3911 

3912 

TM/TPRM SI 

Emerging (P1003.ll [ref]) 

4.10.5.? 

D 


3913 

3914 

Table 4-12 - Transaction Processing Standards Language Bindings 

D 

3915 

Standard 

N/A LIS Ada APL BASIC C C++ 


3916 

ISO/IEC DIS 10026-1 {re/} 

• 


3917 

ISO/IEC DIS 10026-2 {re/} 

• 


3918 

ISO/IEC DIS 10026-3 {re/} 

• 


3919 

POSIX. 11 {re/} 

• • 


3920 

Standard 

COBOL C-LISP Fortran Pascal PL/1 Prolog 

D 

3921 

ISO/IEC DIS 10026-1 [ref] 


D 

3922 

ISO/IEC DIS 10026-2 {re/} 


D 

3923 

ISO/IEC DIS 10026-3 {re/} 


D 

3924 

3925 

POSIX. 11 {re/} 


D 

3926 

NOTE: N/A — Language bindings are not appropriate for this standard. 


3927 

LIS — Language-independent specification is available. 


3928 

Ada, APL, BASIC, — Language-dependent specifications exist. 



3929 4.10.5.1.3 National Standards 

3930 None. D 

3931 4.10.5.2 Emerging Standards in the POSIX OSE 
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3932 OSI Distributed Transaction Processing (DTP) 

3933 ISO/IEC DIS 10026-1 {refs 

3934 ISO/IEC DIS 10026-2 {ref 

3935 ISO/IEC DIS 10026-3 {ref 

3936 These standards, developed by ISO/IEC JTC 1/SC21/WG5, deal expressly with the 

3937 OSI services and protocols for transaction mode communications in an OSI 

3938 environment. 

3939 These standards provide for some of the communications services described in D 

3940 4.10.4.1. D 

3941 POSIX. 11 POSIX Transaction Processing 

3942 POSIX.il {ref 

3943 The POSIX.il working group, formed in 1989, is chartered to work on a profile for 

3944 Transaction Processing within the POSIX OSE. In the process of developing that 

3945 profile, it has identified a number of gaps in the standards coverage and is in the 

3946 process of proposing base standardization activities to address those gaps. 

3947 Specifically, P1003.ll is currently working on the following services identified 

3948 earlier: 

3949 — Transaction Manager (TM) Services provided at the Transaction API. 

3950 — Services provided at the Transaction Manager/TP Resource Manager 

3951 (TM/TPRM) SII. A typical TPRM is a database manager (e.g., SQL). 

3952 RJG: The above list should be adjusted later to reflect the then current state of 

3953 ,11’s activities (in terms of approved PARs.) If no PAR is approved by the beginning D 

3954 of formal ballot, I’ll fix this prose and move it to the Gap section. D 

3955 POSIX.il is working to assure that POSIX Transaction Processing work is con- 

3956 sistent with the emerging work of OSI DTP (cited above), certain ongoing work of 

3957 X/Open TP, several related POSIX activities (POSIX. 1 {2}, POSIX.4 {ref, POSIX.8 

3958 {ref) and the work of ANSI X3T5.5 (RPC). 

3959 4.10.5.3 Gaps in Available Standards 

3960 4.10.5.3.1 Standards/Specifications Outside the POSIX OSE 

3961 Existing standards and emerging standards do not adequately address all the 

3962 requirements identified earlier. While POSIX.il is addressing some of the gaps, 

3963 there are many other gaps still not being addressed by formal standards commit- 

3964 tees. Most notable is the work of X/Open TP. While not formally a standards 

3965 making body, it is addressing most of the gaps, and its output will be potentially 

3966 useful as the basis of a formal standard. 
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3967 X/Open TP 

3968 This group published an “Online Transaction Processing Reference Model” in 

3969 1987 and in 1990 published “Preliminary Specification—Distributed Transaction 

3970 Processing: The XA Specification.” The group is studying the use of OSI DTP, two- 

3971 phase commit, and global transaction identifiers. The group is also actively 

3972 exploring APIs in support of peer-to-peer distributed transactions. 

3973 The work of this group addresses several of the services addressed in this clause, 

3974 including transaction demarcation and conversation services. 

3975 Consideration is also being given to allowing alternative interoperability stan- 

3976 dards including proprietary mechanisms. Additional APIs are being defined by 

3977 X/Open TP to facilitate this. 

3978 4.10.5.3.2 Unsatisfied Service Requirements 

3979 Other than the work of X/Open TP, the following areas are not currently being D 

3980 addressed by standardization activities: communications, terminal communica- D 

3981 tions, program scheduling, message queueing, management, monitoring, model- D 

3982 ing, directory/namespace, recovery/restart, test, and system configuration. D 

3983 4.10.6 OSE Cross-Category Services 

3984 Not applicable. d 

3985 4.10.7 Related Standards 

3986 CCR 

3987 The following standards relating to commitment are related to the ISO/IEC DIS 

3988 10026 series and are referenced in DIS 10026: 

3989 ISO/IEC DIS 9804-3 {reft 

3990 ISO/IEC DIS 9805-3 {ref 

3991 See 4.3 for more information. 

3992 Remote Procedure Call 

3993 ECMA-127 {ref 

3994 See 4.3 for more information. 


3995 SQL Standard Database Language D 

3996 The following standards for SQL also provide transaction demarcation services for D 

3997 relational database access: d 

3998 ANSI X3.135.1 (ISO 9075, FIPS 127) D 

3999 ANSI X3.168 D 
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4000 See 4.4 d 

4001 4.10.8 Open Issues 

4002 None. 
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4003 

4004 


4005 

4006 

4007 

4008 

4009 

4010 

4011 

4012 

4013 

4014 

4015 

4016 

4017 

4018 

4019 

4020 

4021 

4022 

4023 

4024 

4025 

4026 

4027 

4028 

4029 

4030 

4031 

4032 

4033 

4034 

4035 

4036 


4.11 Software Development Environments 

Responsibility: Don Folland 


4.11.1 Overview and Rationale 

Software Development Environments are dealt with as a particular application 
area needing special attention for the following reasons: 

— The domain of Software Development Environments is one of prime impor¬ 
tance. Software development is a major area of expenditure for govern¬ 
ment and large commercial organizations. 

— The need for standardization is being driven not only by the SDE vendors 
and users, but also by the Independent tool developers who want to get 
their tool products on as many vendor platforms as possible. 

— The SDE domain calls not only for portability, but also for particular 
integration and interoperability requirements. 

— The domain is primarily of interest to that user community that has large 
complex software development requirements, but it is also of interest to all 
application areas as software development is an enabling technology for all 
applications. 

Software engineers seek more powerful assistance to improve productivity and 
quality in the software development process. Considered opinion currently favors 
Project Support Environments (PSE) underpinned in such a way that the facilities 
are capable of being implemented on different machines. A PSE needs a base 
holding information such as specifications, designs, code, schedules, configuration 
plans, tests, etc., to support the developers. The interface between the base and 
the tools must ensure portability of the tools. Again, these tools will be supported 
by relevant language standards. 

Certain design methodologies themselves have been modeled formally to establish 
their degree of rigor and self-consistency. Function Point Analysis is one method 
of measuring software systems and computing productivity that is increasing in 
use. It measures inputs, outputs, and entities accessed to determine transaction 
size; it gauges technical complexity by reference to 19 characteristics. These are 
combined to give a measure of systems size. Productivity is the ratio of system 
size in function points to the effort required to produce or maintain the system. 

Generally, software support for the development process is in its infancy and 
effective metrics have not yet been developed. 
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4037 

4038 

4039 

4040 

4041 

4042 

4043 

4044 

4045 

4046 

4047 

4048 

4049 

4050 

4051 

4052 

4053 

4054 

4055 

4056 

4057 

4058 

4059 

4060 

4061 

4062 

4063 

4064 

4065 


4.11.2 Scope 

The problem domain is complex software development, from the generation of an 
idea to the delivery and ongoing support of a solution product set. 

Thus, an SDE may include some or all of the following: 

(1) Software Development Life Cycle 

(a) Requirements analysis 

(b) Logical design 

(c) Physical design 

(d) Functional and interface specification 

(2) Activity support 

(a) Prototyping 

(b) Program development and testing 

(c) Quality assurance and regression testing 

(d) Generation of user documentation 

(e) User training 

(f) Problem report tracking and maintenance 

(g) Maintenance and tracking of schedules 

(3) Configuration Management 

(a) Automatic version management 

(b) Integrity management 

(c) Traceability 

(4) Project Management 

(5) Data Administration 
(a) Access control 

In the context of developing software for a POSIX Open System Environment, 
design will take account of portability and interoperability requirements. The 
SDE tools themselves should be portable. The software development activities 
may be provided with a large set of tools and applications. The SDE must provide 
the necessary support for the integration of all of these tools. 
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4066 4.11.3 Reference Model 

4067 _ 

Environment Adaptation and 
Project Support Tools 

Tool API 


Functional Tools and 
Integration Mechanisms 


Database API 


4068 _ 

4069 Figure 4-22 - Software Development Model 

4070 In this clause the conceptual view of software development is related to the POSIX 

4071 Reference Model (Figure 3-1). The software developer’s view is shown in 

4072 Figure 4-22. The tools used to develop software can be viewed as applications in 

4073 their own right in the context of the POSIX Reference Model, requiring the same 

4074 services from the platform as for Database Management. 

4075 In the Software Development Model, the Environment Adaptation and Project 

4076 Support Tools “layer” provides the essential link between the programmer, 

4077 designer or analyst, the design method, and the development infrastructure. At 

4078 this level are provided the tools and applications that are unique to the project or 

4079 methodology; e.g., project management workbench. It requires support from a 

4080 consistent human-computer interface to the Functional Tools. 

4081 The Functional Tools and Integration Mechanisms embrace the essential tool set 

4082 to enable software developers to build software. It includes simple tools such as 

4083 editors, tools for tool-building, and integration mechanisms. There will be tools 

4084 for Configuration Management, Version Management, and System Administra- 

4085 tion. It is not within the scope of this guide to discuss these in detail. 

4086 The whole software development environment is underpinned by essential 

4087 management systems, such as object management system, a data dictionary, a 

4088 user interface management system, and environment management. A database 

4089 will frequently be established to hold specifications, designs, configuration plans, 

4090 etc. 
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4091 


Software Development Services API: 

— Data Definition and Manipulation Services 

— Data Access and Integrity Services 

— Object Management Services 

— Miscellaneous Services 


Software Development 
Services EEI 


4092 _ 

4093 Figure 4-23 - Software Development Reference Model 

4094 In the POSIX Open System Environment, the software development model can be 

4095 incorporated into the POSIX Reference Model as in Figure 4-23. The model shows 

4096 that the tools and services required by the software developer are part of the 

4097 POSIX Open System Environment and are available through the POSIX OSE API. 

4098 4.11.4 Services Requirements 

4099 Software developers, i.e., designers, analysts, and programmers, use software 

4100 applications to facilitate the complex task of software development. A tool will 

4101 require services from the application platform and will frequently require support 

4102 from another application in the application set. There are many possible imple- 

4103 mentations of tool sets. Descriptions of these are beyond the scope of this guide. 

4104 4.11.4.1 Application Program Interface Services 

4105 The services required at the API are essentially similar to those described for 

4106 Database Management in 4.4.4.1; i.e., Data Definition and Manipulation, Data 

4107 Access, Data Integrity, and such Miscellaneous Services as Data Dictionary. 

4108 4.11.4.2 External Environment Interface Services 

4109 A consistent human-computer interface to the tool set is required. Some of the 

4110 programmer’s tool set will be explicitly focused on windowing services (such as 4.6 4 

4111 and 4.7) and provide assistance to develop software with improved usability. 

4112 Resource data formats must be specified in order to ensure effective information 

4113 interchange [for example, CASE Data Interchange Format (CDIF)], for which stan- 

4114 dards are currently under development under the aegis of the CDIF Technical 
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4115 Committee (see also 4.11.5.2 and 4.5). 

4116 Protocol services are required for the transport of data (see 4.3). 

4117 4.11.4.3 Interapplication Software Entity Services 

4118 Many of the tools depend for interface between one another upon the data 

4119 dictionary/repository, which is a key software component and which may concep- 

4120 tually be regarded as part of the Applications Platform. Included in this category 

4121 will be utilities for servicing the DBMS, such as recovery, reorganization, and res- 

4122 tructure: 

4123 — Object management system 

4124 — User interface management system 

4125 — Database management system 

4126 — Transaction processing management system 

4127 Details of these management systems may be recorded in the data 

4128 dictionary/repository. 

4129 4.11.4.4 Software Development Resource Management Services 

4130 These services are generally not visible to the programmer or software developer 

4131 at the Tools API, usually being provided by the tool building and other software 

4132 development utilities. 

4133 4.11.5 Standards, Specifications, and Gaps 

4134 This subclause describes current accepted standards that are relevant to this area 

4135 in addition to the language standards in 4.1.5 and the database standards in 

4136 4.4.5. 

4137 4.11.5.1 Current Standards in the POSIX OSE 

4138 This subclause briefly identifies the current standards in this area. 

4139 DEF: The following provides place holders for further text to he inserted - assis- 

4140 tance required please. 

4141 4.11.5.1.1 International Standards 

4142 Labeling and File Structure of Magnetic Media 

4143 The following standards refer to the labeling of magnetic media and for the file 

4144 structure on such media to facilitate information interchange: 

4145 Labeling of magnetic tape ISO 1001 {refs 

4146 Labeling of cassette and cartridge ISO 4341 {refs 
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4147 

4148 

4149 

4150 

4151 

4152 

4153 

4154 

4155 

4156 

4157 

4158 

4159 

4160 

4161 

4162 

4163 

4164 

4165 

4166 

4167 

4168 

4169 

4170 

4171 

4172 

4173 

4174 

4175 

4176 

4177 

4178 

4179 

4180 

4181 

4182 

4183 


Table 4-13 - Software Development Standards Activities 


Service Specification Subclause 


Miscellaneous Services: 


Labeling of magnetic tape 

ISO 

1001 

{ref 

4.11.5.? 

D 

Labeling of cassette and cartridge 

ISO 

4341 

{ref 

4.11.5.? 

D 

Labeling of flexible disks 

ISO 

7665 

{ref 

4.11.5.? 

D 

Volume and file structure for flexible disks 

ISO 

9293 

{ref 

4.11.5.? 

D 

Volume and file structure for CD-ROM 

ISO 

9660 

{ref 

4.11.5.? 

D 

Documentation symbols and flowchart conventions 

ISO 

5807 

{ref 

4.11.5.? 

D 

Documentation of applications 

ISO 

6592 

{ref 

4.11.5.? 

D 

Program flow for sequential files 

ISO 

6593 

{ref 

4.11.5.? 

D 

Data descriptive file for information interchange 

ISO 

8211 

{ref 

4.11.5.? 

D 

Program constructs and conventions 

ISO 

8631 

{ref 

4.11.5.? 

D 

User documentation 

ISO 

9127 

{ref 

4.11.5.? 

D 


Labeling of flexible disks 
Volume and file structure for flexible disks 
Volume and file structure for CD-ROM 
Data descriptive file for information interchange 

DEF: The above-mentioned standards might be more 
Richard Scott’s section 4.5. 

Software Documentation 

There are several standards dealing with documentation to assist with the task of 
software development, and therefore potentially facilitating programmer and 
designer portability, as well as user documentation. 


ISO 7665 {reft 
ISO 9293 {re/} 

ISO 9660 {re/} 

ISO 8211 {re/} 

suitably called out in 


Documentation symbols and conventions for data, pro¬ 
gram and system flowcharts, program network charts, 
and system resources charts 

Guidelines for the documentation of computer-based 
application systems 

Program flow for processing sequential files in terms of 
record groups 

Program constructs and conventions for their represen¬ 
tation 

User documentation and cover information for consu¬ 
mer software packages 


ISO 5807 {ref} 

ISO 6592 {ref} 
ISO 6593 {refs 
ISO 8631 {ref} 
ISO 9127 {refs 
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4184 4.11.5.1.2 Regional Standards 

4185 ECMA has approved ECMA-149 as the standard for the Portable Common Tool 

4186 Environment (PCTE). 

4187 4.11.5.1.3 National Standards 

4188 To Be Provided 

4189 4.11.5.2 Emerging Standards in the POSIX OSE 

4190 This subclause describes the activities currently in progress to further standard- 

4191 ize this area. 

4192 4.11.5.2.1 International Standards 

4193 To Be Provided 

4194 4.11.5.2.2 Regional Standards 

4195 To Be Provided 

4196 CASE Data Interchange Format (CDIF) 

4197 The CDIF Technical Committee is developing a data interchange format to serve 

4198 as an industry standard for exchanging information between Computer-Aided 

4199 Software Engineering (CASE) tools. CDIF is an EIA-endorsed initiative. It 

4200 assumes that two or more tools may interface asynchronously with each other and 

4201 will transfer information from one to another via “CDIF files.” The types of infor- 

4202 mation that may be contained in these files is defined by the CDIF Conceptual 

4203 Models. 

4204 Portable Common Tool Environment (PCTE) 

4205 ECMA TC33 has responsibility for the development and maintenance of PCTE. 

4206 The committee formed a Task Group in 1988 to develop a Reference Model which 

4207 would assist the standardization process. Such a model has been developed 

4208 totally independent of PCTE, and is described in ECMA Technical Report 55. The 

4209 model provides a way to describe, compare, and contrast CASE environment 

4210 frameworks. 

4211 4.11.5.2.3 National Standards 

4212 To Be Provided 

4213 4.11.5.2.4 National Standards 

4214 To Be Provided 
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4215 4.11.5.3 Gaps in Available Standards 

4216 4.11.5.3.1 Standards and Specifications Outside the POSIX OSE 

4217 To Be Provided 

4218 4.11.5.3.2 Unsatisfied Service Requirements 

4219 To Be Provided 

4220 4.11.6 OSE Cross-Category Services 

4221 Not applicable. d 

4222 4.11.7 Related Standards 

4223 To Be Provided 

4224 4.11.8 Open Issues 

4225 — Relationship between methodology and formats 
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Section 5: POSIX OSE Cross-Category Services 


1 Responsibility: Fritz Schulz 

2 The POSIX reference model defines a set of conceptual system building blocks that 

3 collectively describes the Open System Environment. Each building block pro- 

4 vides a specific set of interfaces for access to their associated facilities and ser- 

5 vices. There is another class of services and requirements, however, that may 

6 influence and/or impact the basic architectural building blocks; these are referred 

7 to as OSE Cross-Category Services. 

8 An OSE Cross-Category Service is a set of tools and/or features that, when 

9 applied, may have a direct affect on the operation of one or more of the Open Sys- 

10 tern Components, but it is not in and of itself a standalone OSE component, 
n Examples of OSE Cross-Category Services include internationalization, security 

12 and privacy, administration, etc. Internationalization has a number of attributes 

13 that influence multiple OSE components; supporting multiple coded character 

14 sets, for example, will affect end-user interfaces, operational message input and 
is output, screen display, data collating sequences in programming languages and 

16 database systems, etc. 

17 This section will deal with the general characteristics of OSE Cross-Category Ser- 

18 vices as applied to the OSE architectural components and to the profiles and 

19 domains that characterize application environments. The specific 

20 impact/influence of an OSE Cross-Category Service will be described in the 

21 appropriate subclause of Section 4 that deals with individual OSE Components. 

22 Initially, this section will address Internationalization, Security and Privacy, and 

23 System Administration; however, it is anticipated that other OSE Cross-Category 

24 Services will be identified as the concept is applied to the model. 

25 This section describes issues that should be considered in writing profiles, and is 

26 organized so that subclauses for each OSE Cross-Category Service points to, and 

27 addresses issues adjacent to each of the service categories identified in Section 4. 

28 These issues defined areas that need to be traded off to arrive at balanced solu- 

29 tions for a specific profile. It is expected that the specific trades would be made by 

30 the profiler, but that this clause could give guidance for trading and could also be 

31 used to accumulate lessons learned. 
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32 5.1 Internationalization 

33 Responsibility: Ralph Barker D 

34 5.1.1 Overview and Rationale 

35 Historically, information systems intended for use within a particular national or 

36 cultural market have been designed specifically for the requirements of that 

37 market. If the vendor or developer was based in a country other than that of the 

38 target market, this was typically accomplished through substantial re- 

39 engineering the features of an existing system designed for some other country, 

40 and doing so at considerable cost. As the developer desired to market the system 

41 in additional countries, the process of re-engineering was repeated for each new 

42 national or cultural market. Application software developers were faced with the 

43 same problem. The very nature of this style of development produced little con- 

44 cern for portability across national or cultural boundaries, or interoperability 

45 between them. Users or organizations that needed to operate in multiple national 

46 or cultural markets typically did so with multiple, generally incompatible, infor- 

47 mation processing systems. 

48 The interfaces provided by the POSIX Open Systems Environment (POSIX OSE) 

49 can be generalized, however, through the use of internationalization, to extend 

50 across national and cultural boundaries. Such a model provides the foundation 

51 for international portability of application software, increased user portability, 

52 and enhanced interoperability and data exchange capabilities. The task of inter- 

53 nationalization is to ensure that the services provided by the POSIX OSE, and the 

54 interfaces between such services, are specified in such a way that they can be 

55 easily used all over the world. Additionally, as the user is likely to require ser- 

56 vices from any or all of the service categories of the POSIX OSE, internationaliza- 

57 tion impacts all areas of the POSIX OSE, and should be viewed as an OSE Cross- 

58 Category Service. Since the internationalization aspects of general OSE services 

59 and application program interface (API) services are similar for all of the POSIX 

60 OSE service categories, they are discussed here rather than repeating them in 

61 each of the services sections within this guide. 

62 The ability of the service categories of the POSIX OSE to support multiple natural 

63 languages, and the underlying cultural conventions, is a two step process. These 

64 two steps are generally referred to as “internationalization” and “localization.” 

65 First, the interfaces between the service categories are generalized, so that they 

66 are not oriented to the requirements of any particular natural language or set of 

67 cultural conventions (internationalization). Then, facilities are provided by the 

68 POSIX OSE that allow the user to select the desired natural language and cultural 

69 conventions (localization). Tools are provided to facilitate this process. 

70 Within this context, cultural conventions, while discussed more fully later in this 

71 clause, may be viewed as various aspects of how information is presented to the 

72 user. Different cultures, for example, use different formats for dates and numeric 

73 values and use different currency symbols. The interfaces provided by the POSIX 

74 OSE should allow the information to be presented to the user in the appropriate 
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75 format as well as the appropriate natural language. 

76 5.1.2 Scope 

77 The POSIX OSE provides services that are necessary to support users, irrespective 

78 of their particular natural language or cultural conventions. While it is not 

79 expected that every implementation of the POSIX OSE would provide support for 

80 all possible natural languages and cultural conventions, the specification of the 

81 services and the interfaces within the POSIX OSE should not preclude such sup- 

82 port. In addition to the service and interface requirements described here, it 

83 should be noted that internationalization is affected by a number of elements that 

84 are beyond the scope of this guide. Actual implementations of the international- 

85 ized POSIX OSE, for example, may need to consider the impact of multiple sets of 

86 governmental and regulatory agencies, international data communication stan- 

87 dards and other elements which are presently not specified within the POSIX OSE, 

88 such as data portability between localized information processing systems. 

89 Service requirements differ from country to country and even between users 

90 within one country. Many users, for example, may require the simultaneous sup- 

91 port of multiple natural languages and cultural convention sets. Therefore, the 

92 basic internationalization requirement within the POSIX OSE is to provide a set of 

93 services and interfaces that allow the user to define, select, and change between 

94 different culturally related application operating environments supported by the 

95 particular implementation. Specifically: 

96 — The POSIX OSE must provide the means of adjusting the output of specific 

97 functions and utilities to support different natural languages, cultural con- 

98 ventions and character sets as may be required by the supported natural 

99 languages. 

100 — A user should have the capability to select an internationalized user 

101 environment that specifies a particular set of data presentation characteris- 

102 tics, including cultural conventions, character sets and native language. 

103 — An implementation of the POSIX OSE should be able to concurrently sup- 

104 port different applications functioning in different internationalized user 

105 environments, supplying different sets of natural languages, cultural con- 

106 ventions and character sets for different users. 

107 — The capability of supporting different internationalized user environments, 

108 and the associated natural languages, cultural conventions and character 

109 sets, should not require any changes to the logic of existing application pro- 

no grams. 

111 — The effect of the user selecting a new internationalized user environment, 

112 and its associated natural language, cultural conventions and character 

113 set, should be transparent to application programs. 

114 — The model should be flexible, to support future extensions and require- 

115 ments. 
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116 5.1.3 Reference Model 

117 Internationalization is an OSE Cross-Category Service, spanning all OSE service 

ns categories. While various reference models have been used in published technical 

119 papers to depict internationalization issues, the internationalization services 

120 described in this clause conform to the POSIX OSE Reference Model. 

121 5.1.4 Service Requirements 

122 The POSIX OSE must provide services on different levels: general service require- 

123 ments to be satisfied for any requesting program; API service requirements to be 

124 satisfied at the application program interface for a specific program; and a set of 

125 tools to support the localization of systems and applications. This subclause 

126 (5.1.4) will discuss these different service requirements in detail. In examining 

127 these service requirements, it is helpful to draw a distinction between those ser- 

128 vices which are required to support the portability of an application platform 

129 across cultural boundaries, and those services which are required to support the 

130 portability of an application across one or more sets of cultural conventions which 

131 may be supported on a single application platform. 

132 5.1.4.1 General Service Requirements, Application Platform 

133 Internationalization requirements are focused on support and handling of: 

134 — Character sets and data representation 

135 — Cultural conventions 

136 — Natural language support 

137 5.1.4.1.1 Character Sets and Data Representation 

138 The character set for the English language can easily be satisfied by the standard 

139 ASCII character set (American Standard Code for Information Interchange). The 

140 ASCII code uses 7 bits to uniquely identify each of the 95 available characters. 

141 For European and American languages beside English, the number of local char- 

142 acters is much larger. The far-east requirements for thousands of pictograms add 

143 yet another dimension to the coding rules and techniques. 

144 Different standards address the methods by which the local character repertoires 

145 can be coded for unique identification. While replacement of seldom-used charac- 

146 ters in the 7-bit codings can support a single additional language besides English, 

147 8-bit coding schemes are used to satisfy multiple languages concurrently by 

148 assigning an additional 96 graphic characters to the available repertoire. An 

149 example is ISO 8859-1 (the extended ASCII code), which can support all of western 

iso Europe, America, Australia, and other English speaking countries all over the 

151 world. For Eastern Europe, Greece, Russia, Arabia, and many other countries, 

152 other 8-bit codes are defined. Japan, China, Korea, and Taiwan have so many 

153 characters in their repertoire that 16 bits are needed to identify them clearly. 

154 Work is under way to develop a multi-octet character set with up to 32 bits per 


Copyright © 1991 IEEE. All rights reserved. 

This is an unapproved IEEE Standards Draft, subject to change. 


5.1 Internationalization 


179 



P1003.0/D13 


GUIDE TO THE POSIX OPEN SYSTEMS 


155 coded character; this method will allow concurrent use of all possible languages in 

156 the same application. 

157 Because different coding schemes are used, it is important that the application 

158 platform have the potential capability of supporting all of them. It is also impor- 

159 tant that the application platform has the capability to represent (display, print) d 

160 the data correctly. It is also important that an application be able to determine in d 

161 which coded character set data items are stored on disk or tape. Otherwise, it is D 

162 impossible for the application to interpret the data correctly. Currently the user D 

163 must control the consistent use of the same coded character set within an applica- D 

164 tion, but in the future the application platform should be able to provide D 

165 identification methods for the coded character sets used for data storage, process- d 

166 ing, communication, and presentation. It might also be advantageous for the D 

167 application to be able to prohibit users from updating data stored in one coded D 

168 character set with data in another coded character set since this would immedi- D 

169 ately corrupt data bases or flat files. Therefore it may be necessary in the future D 

170 to provide a method of announcing the coded character set in which data are d 

171 stored, processed, communicated, and presented. d 

172 The general service for support of character sets and data representation in an 

173 international environment are: 


174 

175 

176 

177 

178 

179 

180 
181 

182 

183 

184 

185 

186 

187 

188 

189 

190 

191 

192 

193 

194 

195 

196 

197 

198 


(1) Coded character set independence: the ability of the application platform 

to input, store, manipulate, retrieve, communicate, and present data 
independent from the coding scheme used. This includes 7-bit, 8-bit, 16- 
bit, and multi-octet coded character sets. d 

(2) Character set repository: the ability of the application platform to main¬ 
tain and access a central character set repository. This repository con¬ 
tains all coded character sets used throughout the platform and specifies 
relevant information about them: 

— Code format: the repository contains information, if characters are 
coded in 7 bits, 8 bits, 16 bits, or any other format. 

— Data class definition: the definition that a character is considered 
numeric, alpha, etc., by the programming languages. This 
classification can vary for the same character from country to country. 

— Collating rules: different character sets have different coding for 
characters. Thus, comparison of strings of such coded characters 
must follow rules defined for the specific character set. Culturally 
dependent additional collating rules are discussed in 5.1.4.1.2. 

— Lower- to uppercase mapping: this defines the rules of mapping, if for 
a specific character no upper- or lowercase is available. Examples are 
the lower case umlauts which do not have uppercase representations 
in Switzerland; the uppercase forms are A, O, or U, respectively, fol¬ 
lowed by a lowercase “e”. 

— Escapement rules: some languages like Hebrew and Arabic are writ¬ 
ten from right to left; numbers within text in these languages are 
written from left to right. It is necessary to store these escapement 
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199 


rules with the character set. 


200 

201 

202 


— Presentation rules: the application platform should have the ability 
of providing fallback presentation rules for the presentation of coded 
characters that have no associated graphic shape. 


203 

204 

205 

206 
207 


(3) Character set identifier: the application platform should provide the 
ability to uniquely identify each coded character set to allow compatibil¬ 
ity checks and translation or transliteration to and from other registered 
character sets. This ensures data integrity in the communication of data 
across computers and networks. 


208 

209 

210 
211 
212 


(4) Character set selection: the application platform should allow the end- 
user or the application to select the coded character set to be used; other¬ 
wise, the application must automatically select a default coded character 
set according to preset parameters. It must be possible to switch to other 
coded character sets and to invoke translation routines where required. 


213 

214 

215 


Editor’s Note: From here to the end of 5.1, the term “[operating] system” D 
has been replaced numerous times with “application platform”, without D 
further diff marks. D 


216 

217 

218 

219 

220 
221 
222 
223 


(5) Data announcement: the application platform could benefit from having D 
the ability to recognize the coded character set of data entities (files, mes- d 
sages, etc.). One way of doing this is to store the character set identifier 
together with the data; standardization efforts are under way to formal¬ 
ize this process, with consideration being given to the level of granularity 
of such identification (e.g. file, word, character). The announcement 
enables the application to prohibit updates with data coded in other char¬ 
acter sets, thus ensuring data integrity even in distributed systems. 


224 

225 

226 

227 

228 
229 


(6) Data presentation: the application platform should be able to present D 
data on different display or output devices, potentially according to rules d 
in a repository, including escapement of characters and selection of dif- D 
ferent shapes. Preparing data for presentation may involve extensive 
translation and transliteration due to potential hardware limitations of 
the printers and displays used in a particular installation. 


230 

231 

232 

233 

234 


(7) Data communication: the application platform should be able to transmit D 
and receive data from communication systems and to maintain the 
integrity of the information. In an internationalized environment, this D 
capability might include data translation due to different coded character d 
sets being used by different service categories of the application platform. 


235 

236 

237 

238 

239 

240 


(8) Data input: the ability to enter data is not necessarily controlled by the 
application platform. The complexity of the input of Asian languages 
though might strongly support the idea of a standardized input mechan¬ 
ism interface. Depending on how other internationalization service D 
requirements are met, it might also be beneficial for input data to carry D 
some form of character set identification. D 
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241 


5.1.4.1.2 Cultural Conventions 


242 Besides using different characters and different languages, countries throughout 

243 the world have also developed quite different cultural conventions. Even within 

244 one country we can find significantly different cultural environments. The prime 

245 example is Switzerland, where French, German, Italian, and Rhaeto Romanic are 

246 officially accepted languages. Combined with the language preferences are con- 

247 ventions about the formats of time, date, numeric values, and measuring systems. 

248 Currency symbols, paper formats, hyphenation, and collating are dependent on 

249 cultural conventions. End-user-oriented applications have to address these issues 

250 to provide a familiar local view, which helps to prevent operating errors. 

251 The general service requirements for cultural conventions are: 

252 ( 1 ) Cultural convention repository: The application platform must have the 

253 ability to store and access rules and conventions for cultural entities. 

254 These might be areas with a common language, geographic areas, or 

255 areas with common cultural or historic background. The repository 

256 should contain specifications and presentation rules for: 

257 — Date and time formats: indicating the formats associated with the 

258 particular cultural entity. For example, while in the US the date is 

259 expressed in the format month/day/year, the European preferred for- 

260 mat is year-month-day for data processing purposes and day-month- 

261 year in personal use. Japan counts the years according to the reign of 

262 the current emperor. Additionally, twenty-four-hour clocks, which are 

263 prevalent in Europe, are commonly used only in military circles in the 

264 US, while the terms “am” and “pm”, denoting morning and afternoon, 

265 are used by the general public. These are only a few examples for the 

266 cultural differences in this area. The application platform must be 

267 able to store the preferred forms for date and time for a specific cul- 

268 tural entity and make it available upon request in this format. 

269 — Week and day numbering: in Europe, the week starts on Monday, in 

270 the US on Sunday. The application platform should be able to supply d 

271 the requesting program with the needed information, potentially from D 

272 a repository according to specified rules. 

273 — Formats of numeric fields: handling of numeric fields in unfamiliar 

274 formats is one of the major reasons for human errors. The application 

275 platform must provide the service to format the values according to 

276 specifications in the repository. The characters that signify the 

277 decimal point (comma, period, etc.) must be defined, as well as the 

278 number of decimals, the grouping of digits before the decimal point 

279 and the presentation of negative values. 

280 — Currency symbols and field length: the handling of currency symbols 

281 in the different cultural areas must be provided by the general inter- 

282 nationalization services. The currency symbols might be more than 

283 one digit long and can appear before or after the currency field. The 

284 format of currency fields might differ from that of numeric fields; for 
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285 

286 

287 

288 

289 

290 

291 


292 

293 

294 

295 

296 

297 

298 

299 

300 

301 

302 

303 

304 

305 

306 

307 

308 

309 

310 

311 

312 

313 

314 

315 


example, in Portugal the $-sign is used as the decimal point. Informa¬ 
tion about these conventions must be stored in the repository and be 
used by the application platform for local formatting of currency 
fields. Not necessarily a service, but similarly important, is the 
understanding, that due to the value of different currencies, the field 
lengths must be considered carefully. Also some currencies do not 
have decimals (e.g., Italian Lira). 


D 


— Paper formats: internationally usable and portable applications must 
be able to print on different paper formats. While quart format is 
predominant in the US and the far east, the DIN standardized A- 
formats are used in Europe. Printer drivers must be able to adjust 
their output to local formats, defined in the cultural convention repo¬ 
sitory. 

(2) Cultural repository selection: these repositories must be available to all 
applications. Users and applications must be able to select a repository 
from the application platform; a default value must be provided if no 
selection is made. An additional service allows dynamic switching to 
other repositories upon user or program requests. 

(3) Collating rules: besides the generic binary and character-set-dependent 
sorting rules, the application platform must have the ability to sort data 
according to local rules, defined in the repository. An example for 
culture-dependent collating rules is the handling of umlauts; while they 
are sorted with the base characters in Austria, they are sorted at the end 
of the alphabet in Sweden. Adding complexity, they can be sorted dif¬ 
ferently within one country between normal business use, such as dic¬ 
tionaries, and in telephone books. Other idiosyncrasies are the sorting of 
one character as two (the German “sharp-s” sorts as “sz” in Austria and 
“ss” in Germany), or two characters as one (the Spanish “ch” sorts as one 
character), or the position of accented characters in a string, and more. 
User-defined collating tables in the cultural convention repository allow 
culture or application-dependent sorting services. 


316 5.1.4.1.3 Natural Language Support 

317 The POSIX OSE must give users the ability to select a natural language for their 

318 dialogue with the system and applications. While it is unrealistic to expect all 

319 application platforms to support all possible natural languages, error messages, 

320 online documentation and help facilities, selection menus, and the relevant user 

321 interaction with these services must be prepared for translation into the sup- 

322 ported user-selectable natural language. Additionally, the POSIX OSE must sup- 

323 port differences between the natural language selected by the user for interaction 

324 with the application platform and that selected for use within a particular appli- 

325 cation. For word- and text-processing, the service includes hyphenation and spell 

326 checking with possible thesaurus support in different languages. The problem is 

327 complicated by the fact that data can contain text in different languages in the 

328 same document. 
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329 The service requirements for natural language support are: 


330 

331 

332 

333 

334 

335 

336 

337 

338 

339 

340 

341 

342 

343 

344 

345 

346 

347 

348 

349 

350 

351 

352 

353 

354 

355 

356 

357 

358 


359 

360 

361 

362 

363 

364 

365 

366 

367 

368 

369 

370 


(1) Multilingual capability: the application platform should be able to sup- d 
port more than one language simultaneously. For example, one process D 
might be providing French language capabilities while another process D 
operated in Japanese. The application platform must be able to let users d 
select their preferred languages for communication with the application 
and allow them to switch dynamically to another language. The applica¬ 
tion platform must also have the capability to assign a default language, 
based on parameters for the application platform, the specific worksta¬ 
tion, the user identification, or the application. 

(2) Natural language message system: the application platform must have 
the capability to present (display, print, ...) messages, menus, forms, 
and online documentation in the language, selected by the user. The 
application platform must be able to support multiple languages simul¬ 
taneously for different users and it must ill actually be implemented. 

703 One aspect of an SSP may be that it mandates conformance with the POSIX secu- 

704 rity extensions. 

705 Security interface specifications are intended to assist in the construction of a e 

706 secure system. They do not, in isolation, provide any protection against threats to 

707 a system. 

708 5.2.3 Reference Model 

709 The reference model for security is the same as the model shown in Figure 3-3. E 

710 Security has an impact on all of the APIs and EEIs in the model. E 

711 5.2.4 Service Requirements 

712 Through an analysis of the potential threats and requirements of the system, the 

713 system security objectives and hence the necessary System Security Policy (SSP) 

714 rules may be derived. This analysis must also take into account appropriate cor- 

715 porate, legal, and standardization requirements. 

716 System confidentiality, integrity, availability, and accountability may be sup- 

717 ported by the following security objectives: 

718 Technical Security Objectives 

719 — Identification and Authentication. A system entity, such as a user or sys- 

720 tern element, must prove that its claimed identity is legitimate, such that 

721 another system entity may place confidence in that claimed identity. 

722 — Access Control. Access to system resources will be restricted to authorized 

723 entities only. Residual data contained within an object will be securely 

724 erased before it may be reused by a system entity. 

725 — Accountability and Audit. System users must be made accountable for 

726 their actions. Audit trails of these actions will then be maintained and 
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727 utilized such that unauthorized system activity will be detected. 

728 — Accuracy. The system must ensure that the correctness and consistency of 

729 security-relevant information is maintained. 

730 — Availability. System resources will be provided to users in a consistent and 

731 reliable manner. 

732 — Data Exchange. Data transmitted between system users and/or elements 

733 will be protected from unauthorized interference or viewing. Originators 

734 and recipients of data will be authenticated and will be able to mutually 

735 prove their respective participation in the transaction. 

736 Nontechnical Security Objectives 

737 — Assurance. The security of the system must be specified, designed, imple- 

738 mented, tested, and maintained in such a way that confidence can be 

739 placed in the correct and effective operation of the system. Also, procedures 

740 must be specified to ensure continued confidence in the security of the sys- 

741 tern in the event that the system is modified in some manner. 

742 — Security Roles and Responsibilities. Security activities must be partitioned 

743 and allocated to identifiable security administrators who will then be 

744 responsible for ensuring that their allocated task is satisfactorily per- 

745 formed. 

746 — Secure Operating Procedures. Procedures must be written that will guide 

747 system administrators and users as to the correct procedure to follow in the 

748 event of some security-relevant occurrence. 


749 5.2.4.1 Application Programming Interface Services 

750 E 

751 The POSIX security interfaces will support Audit, Privilege, Discretionary Access 

752 Control (DAC), Mandatory Access Control (MAC), and Information Labels (ILs). E 

753 The audit services include: E 

754 — Ability to record the user identification for actions within an audit trail E 

755 — Ability to process the audit trail e 

756 — Ability to use the audit trail to generate alarms e 

757 The privilege control services include: E 

758 — Ability to grant users only the minimal security required to perform a task E 

759 This will minimize the impact of a subverted security administrator or unauthor- E 

760 ized usage of a security administrator role. E 

761 The discretionary access controls (DAC) provide the following services: E 
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762 — Ability to control fine-grained user access to objects e 

763 — Ability to provide extended user access bits beyond the traditional user- e 

764 group-other E 

765 — Ability to support access control lists (ACL) E 

766 The mandatory access controls (MAC) and information labels (IL) support policies E 

767 for labeling: E 

768 — Ability to associate a MAC label with an object e 

769 — Ability to label information (e.g., physical document handling restrictions) E 


770 5.2.4.2 External Environment Interface Services 

771 Note to reviewers: This subclause will be provided in a later draft. Mock ballot E 

772 reviewers are welcome to submit comments on the types of services required at the E 

773 EEI. E 

774 5.2.5 Standards, Specifications, and Gaps 

775 Table 5-2 lists the current, emerging, and gaps in security standards. E 


776 Table 5-2 - Security Standards E 

777 _ 


778 

Service 

Type 

Specification 

Subclause 

E 

779 

System Security 

E 

IEEE P1003.6 API 

5.2.5.2 

E 

780 

Access Control 

E 

ISO/IEC 8613 

5.2.5.2 

E 

781 

Directory Authorization 

S 

CCITT X.509 

5.2.5.1 

E 

782 

Security 

G 

ECMA CMA 138 

5.2.5.3 

E 

783 

784 

Trusted Systems 

G 

DOD 5200.28-STD 

5.2.5.3 

E 

785 

5.2.5.1 Current Standards 




E 


786 ISO 7498-2, Information Processing Systems—Open Systems Interconnection Refer- E 

787 ence Model, Security Architecture. E 

788 ISO/IEC 8613, Information Technology—Text and Office Systems—Office Docu- E 

789 ment Architecture (ODA) and Interchange Format. E 

790 CCITT X.509, Message Handling System, ISO/ CCITT X.400 Directory Authentica- E 

791 tion Framework. E 

792 ECMA CMA 138, Security In Open Systems—Data Elements and Service E 

793 Definitions. E 
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794 5.2.5.2 Emerging Standards E 

795 Information Retrieval, Transfer and Management For OSI—Draft Access Control E 

796 Framework, ISO/IEC SC21 / WG1. E 

797 Draft Addendum to ISO 8613 On Security E 

798 The P1003.6 scope is limited to security extensions for those interfaces defined E 

799 within the base POSIX interface specification (POSIX.1 {2}). Issues not addressed E 

800 within the P1003.6 scope include noninterface-specific architectural assurance E 

801 issues and communications security. E 

802 5.2.5.3 Gaps in Available Standards E 

803 The Information Technology Security Evaluation Criteria, Version 1.2, 28 June E 

804 1991. E 

805 US DoD, DOD 5200.28-STD, Trusted Computer System Evaluation Criteria. E 

806 Trusted Network Interpretation E 

807 Trusted Database Interpretation e 

808 Computer Security Subsystem Interpretation E 
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809 5.3 Information System Management 

810 Responsibility: Don Folland, Neil Croft 

811 5.3.1 Overview and Rationale 

812 Information System Management issues are considered in this clause. The sub- E 

813 ject is concerned with the effective management and control of the complete set of e 

814 resources that comprise an information system. The tools in support of the ser- E 

815 vices required by system managers need to reflect the portability and interwork- E 

816 ing attributes of open systems and fit the Open System Environment Reference E 

817 Model (Figure 3-3). It is necessary to consider a variety of system management E 

818 support scenarios (central management, dispersed management, or hybrid), E 

819 addressing both distributed systems and standalone systems. The issues apply to e 

820 application software or software components of the application platform. It is E 

821 necessary to support automated management and operation of the IT infrastruc- E 

822 ture and address a wide variety of licensing scenarios. e 

823 5.3.2 Scope 

824 This category includes services and policies that address the administration of the 

825 overall information system required by any organization, including: 

826 — Information Management 

827 — Processor Management (e.g., Add new user) 

828 — Network Management 

829 — Configuration Management 

830 — Security Management (e.g., Authentication, Key Management) 

831 — Accounting Management 

832 — Performance Management 

833 Administration services accessible from the API may have Programming 

834 Language or Language Binding service specifications associated with them. 

835 These services are defined to provide system and network administrator 

836 portability. 

837 5.3.3 Reference Model 

838 The Reference Model for system management is the same as the model shown in e 

839 Figure 3-3. System management impacts all of the APIs and EEIs in the POSIX E 

840 Open System Environment Reference Model. e 
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841 5.3.4 Service Requirements 

842 The following services should be provided: E 

843 5.3.4.1 Processor Configuration Management 

844 Configuration management consists of four basic functions: identification, con- 

845 trol, status accounting, and verification. 

846 Identification involves specifying and identifying all components of an IT infras- 

847 tructure. 

848 Control implies the ability to agree and “freeze” configuration items (CIs) and 

849 then to make changes only with agreement of the appropriate named authorities. 

850 Control is concerned with ensuring that none of the CIs shown is altered or 

851 replaced and that no CIs are added without appropriate authorization. 

852 Status accounting involves the recording and reporting of all current and histori- 

853 cal data concerned with each CL Status accounting maintains records of the 

854 current, previous and planned states and attributes of the CIs and tracks these 

855 states and attributes: for example, as the status of a Cl changes from “develop- 

856 ment” through to “test,” “scheduled to go live,” “live,” and through to “archived.” 

857 Verification consists of a series of reviews and audits to ensure that there is con- 

858 formity between all CIs and the authorized state of CIs as recorded in the 

859 configuration management database (CMDB). It is concerned with checking that 

860 the physical CIs actually match the authorized system as described in the CMDB. 

861 5.3.4.2 Network Configuration Management 

862 To ensure the viability of network services the configuration of systems and ser- 

863 vices must be controlled and managed. Effective configuration management will 

864 produce a minimum risk environment. 

865 Configuration management procedures must ensure that details are provided for 

866 network equipment and systems covering: 

867 — Configuration activities—how to configure the network equipment 

868 — Security controls 

869 — Access controls 

870 — Configuration history log 

871 — Configuration authority 

872 — Build details 

873 — Fail-back and test records 

874 — Management reporting requirements. 
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875 5.3.4.3 Distributed System Configuration Management 

876 The services here consist of the following: E 

877 — Authentication services for a distributed system environment 

878 — Distributed Naming Service Configuration 

879 — Distributed Time Service Configuration 

880 — X Window system configuration 

881 — Window/Session Manager configuration 

882 5.3.4.4 Software Installation and Distribution 

883 The main types of software to be installed and distributed are application pro- 

884 grams developed in-house, bought-in applications, and utility software and per- 

885 sonal computer software packages. All software needs to be managed effectively 

886 from development or purchase through to the live environment. Unless the distri- 

887 bution and implementation process can be controlled automatically, or from the 

888 center using software tools, procedures must be in place to ensure that distributed 

889 software arrives when expected and is checked for authenticity in whatever way 


890 is practical, and that the software is brought into use when required. The main 

891 procedures involved in software distribution and installation are: 

892 — System management staff at the center to inform remote staff when to E 

893 expect distribution software to arrive. e 

894 — Recipients to report to system management staff when the distributed E 

895 software has arrived successfully. e 

896 — System management staff to check that all software is received as expected e 

897 at locations. e 

898 — System management staff to issue clear instructions about when the E 

899 software is to be implemented. E 

900 — Location staff to report to system management at the center when the E 

901 software has been implemented. The release record on the Configuration e 

902 Management Database will state which installations are to receive the 

903 release. This database must be updated to reflect the receipt and imple- 

904 mentation of the release at each site. 


905 5.3.4.5 License Services 

906 The terms and conditions relating to the supply of software may place legal res- 

907 trictions on the organization (e.g., no unauthorized copies to be made). It is par- 

908 ticularly important therefore that the Configuration Management Database is 

909 updated with details of who holds copies of software items. This assists the 

910 organization in discharging its legal obligations and assists auditors in checking 

911 for the existence of unauthorized copies. 
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912 All authorized copies of licensed or purchased software that are made by system E 

913 management staff should be allocated a unique copy number and recorded in the E 

914 Configuration Management Database together with where they are located and 

915 who is responsible for them. Procedural restrictions should be introduced to 

916 prohibit the unauthorized copying of software, and regular software audits should 

917 include a check for any unauthorized copies. 

918 5.3.4.6 Print Output and Distribution Services 

919 Output and distribution packages control output production and distribution from 

920 the moment the output is planned to the time the user receives the print. The 

921 working criteria need to be set up first; e.g., define who receives the report and 

922 how much of the report the user gets. 

923 The main functions are: 

924 — The report can be limited to parts wanted by the user. 

925 — Multiple copies of the entire report, or of selected sections can be produced. 

926 — Reports are grouped by recipient within delivery location. 

927 — Reports for each job are spooled as a group when the job is complete. 

928 — The number of whole reports and individual pages received by each user 

929 are recorded. 

930 — Report production can be monitored and managed efficiently. 

931 Output and Distribution packages should include the following: E 

932 — Printing and distribution of whole and part reports 

933 — Status (queued, printing etc) of the report tracked 

934 — Online viewing of reports 

935 — Ability to archive report files 

936 — Ability to support a wide range of printers 

937 — Costing and charging functionality 

938 — Security facilities 

939 By using an output distribution package, the delivery of reports to the correct per- 

940 son at the correct location can be ensured. Paper, time, and IT resource are saved 

941 as the users receive only the parts of reports that they need, and can also view the 

942 reports online. The number of pages printed can be controlled. Reports can be 

943 tracked from the time they are created to the time they are delivered to the user, 

944 allowing good security monitoring. 
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945 5.3.4.7 Office Media Management and Backup/Restore 

946 The main services of magnetic tape and data cartridge management systems are: e 

947 — Provide automated support for tape housekeeping and maintenance includ- 

948 ing: 

949 • Allocating tapes and releasing them for reuse helping 

950 • To ensure even patterns of use where appropriate 

951 • Constructing and triggering cleaning schedules 

952 • Maintaining the security of data 

953 — Help automate archiving (vault management) for offsite storage 

954 — Help identify growth requirements 

955 Vault management is concerned with controlling the movement of tape cycles 

956 from one storage location to another. As a tape cycle is used, the tape manage- 

957 ment system automatically logs a different vault identifier against each tape. 

958 A backup strategy is required to control the frequency of backups and the way in 

959 which they are created; e.g., whole volumes to cartridge or individual files to tape. 

960 The backups and restores of system and application software should be separate 

961 from the backups and restores of data. Software and library backups should be 

962 explicitly scheduled and the complete software item or library backed up. The 

963 schedule for backing up files must be fully documented, properly maintained and 

964 adequately safeguarded as the contents of the schedule are required for disaster 

965 recovery purposes. 

966 5.3.4.8 Online Disk Management 

967 The operation of disk management systems requires that they take account of a 

968 range of factors such as retention period, recovery, space fragmentation, disk 

969 overflow, file and record activity levels, and channel use. Some systems merely 

970 report against values or thresholds set, but increasingly they invoke corrective 

971 action. Typically, the corrective action is file and disk reorganization or file and 

972 data archiving. 

973 If a disk management system is used, the constant monitoring and actioning of 

974 requests for disk space can be minimized. Disk space may be collectively pooled 

975 and unused space constantly reclaimed. 

976 5.3.4.9 Job Scheduling 

977 Scheduling involves the continuous organization of jobs and processes into the 

978 most efficient sequence, maximizing throughput and utilization to meet the tar- 

979 gets set in service level agreements (SLA). Jobs are scheduled to ensure: 

980 — SLAs and user requirements are met; e.g., certain jobs need to be run by a 

981 certain time 
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982 — Available capacity is used effectively; e.g., the workload run at any given 

983 time does not exceed the practical capacity. 

984 The minimum services of a scheduler should include: E 

985 — A high upper limit for the number of relationships allowed between jobs 

986 — The ability to schedule by calendar and criteria 

987 — Workload balancing support 

988 — Levels of security 

989 — Ability to restart jobs 

990 — Operator override capability 

991 — Capability to model future workloads. 


992 5.3.4.10 User Administration E 

993 The services here consist of the ability to: E 

994 — Create a new user or group of users e 

995 — Delete a user or group of users e 

996 — Allocate system resources to a user or a group of users e 


997 5.3.4.11 Accounting 

998 An effective cost management system should contribute to the development of a E 


999 sound investment strategy that recognizes and evaluates the options and flexibil- E 

1000 ity available from modern technology. The services here should provide the abil- E 

1001 ity to: e 

1002 — Establish targets for performance e 

1003 — Measure performance against targets e 

1004 — Measure and prioritize resource usage E 

1005 — Monitor assets and maintain records for control purposes E 

1006 — Apportion costs of IT services to users E 

1007 — Report costs to management and users e 


1008 5.3.4.12 Performance Management 

1009 The services here should provide the ability to: e 

1010 — Monitor hardware, software, and network performance E 

ion — Monitor workload and throughput E 

1012 — Set and adjust system parameters to tune performance e 
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1013 — Monitor terminal response time E 

1014 5.3.4.13 Capacity Management 

1015 An effective and efficient capacity management function contains at least the fol- 

101 6 lowing elements: 

1017 — Performance management to monitor and optimize the use of current sys- 

101 8 terns. 

1019 — A capacity management database that contains current and historic data of 

1020 technical and business related interest. This database forms the basis for 

1021 the provision of both tactical and strategic reports on performance and 

1022 capacity. 

1023 — Workload management to identify and understand the applications that 

1024 make use of the system. The understanding of workloads has both a techn- 

1025 ical and business related nature. This involves application sizing to accu- 

1026 rately predict the performance and required capacity of new applications. 

1027 — Capacity planning to accurately plan the required hardware resource and 

1028 associated cost for the future and to predict the effect on performance and 

1029 capacity of both tactical and strategic plans. 

1030 5.3.4.14 Fault Management E 

1031 These services allow the system to react to the loss or incorrect operation of sys- 

1032 tern components at various levels (hardware, logical, services, etc.). The classical 

1033 model of fault tolerance has a three-step approach. The three steps are fault 

1034 detection, fault isolation, and fault recovery. Typically implementations divide 

1035 these steps into multiple steps or integrate them into one or two steps. Addition- 

1036 ally, fault diagnosis services support the other steps in the treatment of a fault. 

1037 Various fault tolerance strategies, such as checkpointing and voting, are imple- 

1038 mented as a collection of services comprising one or more of the steps in the fault 

1039 tolerance classical model. For example, services involved in implementing a 

1040 three-node voting scheme will include a vote comparator service (fault detection), 

1041 vote analyzer service (fault isolation/fault diagnosis), a service to pass the major- 

1042 ity “answer” through (fault recovery) as well as a service to disable the faulty 

1043 resource and reconfigure the voters (fault recovery/reconfiguration). 

1044 Fault Detection 

1045 Fault detection services are concerned with determining when a fault has 

1046 occurred in the system. Fault detection services are both passive and active. 

1047 Active services are those that attempt to determine the status of various system 

1048 components by testing those components. Passive services, on the other hand, try 

1049 to ascertain system components by passively gathering information and watching 

1050 the behavior of the system. 
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1051 Fault Isolation 

1052 Fault isolation services attempt to determine the component at fault and segre- 

1053 gate the faulty component from the rest of the system. Services may be shared 

1054 between the fault detection and isolation service library in that they perform both 

1055 functions. 

1056 Fault Recovery 

1057 Fault recovery services attempt to bring the system into a consistent state. These 

1058 services may be very interrelated to the scheduling services, network services, 

1059 and data base services, depending on the recovery scheme used. 

1060 Redundancy of resources is many times needed to support fault recovery. 

1061 Resources may include data, process, processor, disk drive, etc. 

1062 As parts of the system fail, it may no longer be possible to satisfy all the require- 

1063 ments of the application. Services to support graceful degradation may be used to 

1064 ensure that critical activities do not fail. 

1065 Fault Diagnosis 

1066 These services deal with the system’s ability to analyze the attributes of a system 

1067 fault and determine its cause. These services tend to be very interrelated with 

1068 fault detection and fault isolation services. 

1069 Fault Avoidance 

1070 These services involve the avoidance of faults before a failure in the system com- 

1071 ponent occurs. If a system can detect that the operation of a component is 

1072 approaching the edge of its operational range, a standby or backup component 

1073 could be phased in to replace it. Another form of fault avoidance is logging of 

1074 shocks, temperature extremes, etc., so that it can be predicted that a component 

1075 will not meet its original expected service life. 

1076 Software Safety 

1077 These services involve the system’s ability to keep application software from caus- 

1078 ing harm to the system’s software, hardware, or user. For instance, a process 

1079 may attempt to write into another process’s memory space without permission. 

1080 A good example of a reliability method that may provide software safety is a 

1081 bounds checker. The checker compares an answer supplied against the bounds. 

1082 If it is not within the bounds, the bounds checker will not allow the answer to pro- 

1083 pagate, possibly causing damage to the system’s integrity. Additionally, it may 

1084 send a fault message (or security violation information, depending on the type of 

1085 answers expected) to the proper service. 

1086 To enhance software safety, other services and processes should be only given the 

1087 resources necessary to complete their job. 
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1088 Status of System Components 

1089 These services involve the obtrusive and nonobtrusive diagnosis of the state of 

1090 system components. For further explanation of these services, see Fault Detec- 

1091 tion and Fault Diagnosis services. These services may additionally need to record 

1092 and/or display information concerning performance, configuration, and general 

1093 system information. 

1094 Reconfiguration 

1095 These services allow the system to reconfigure its view of the world. This services 

1096 allow the system to substitute different resources to perform system functions 

1097 such as substituting a new physical I/O channel to support a logical channel. 

1098 These services are part of the API but their use may be restricted to specially 

1099 authorized programs such as those used by the target system operator. 

noo Maintainability 

noi Maintainability services provide support for the maintenance of a system. A 

1102 major component of that support is the collection and logging of information about 

1103 the operation of the system. Typical information to be logged is: 

1104 — Software and hardware errors during operation 

nos — Processes that failed or almost failed to meet scheduled deadlines 

1106 — Performance metrics for system tuning 

1107 — Times when the system operated in extreme environmental conditions 
nos — Errors reported during startup self-testing 

H 09 — Attempts to violate rules of the system’s security policy. 

mo 5.3.4.15 Security Management 

mi — Configuration of appropriate ACLs for System, User Interface, Storage, Net- 

1112 work, and application software services. 

1113 5.3.5 Standards, Specifications, and Gaps 

1114 There are a number of international and national initiatives to develop standards E 

1115 for system management. E 

1116 Note to reviewers: This subclause will be expanded in a later draft. E 
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5.3.6 OSE Cross-Category Services 

— Security for remote print jobs 

5.3.7 Related Standards 

None. 
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Section 6: Profiles 


1 Responsibility: Fritz Schulz 

2 This section targets those who want to know more about what profiles are and 

3 those who are in the process of developing their own profiles. The latter group 

4 consists of those developing formal “Standardized Profiles” and those developing 

5 less formal profiles for their industry group (e.g., a banking trade association) or 

6 their own company or enterprise for procurement or strategic planning purposes. 

7 Those not involved in the development of profiles should read 6 . 2 . Parts of 6.3 

8 also may be useful, especially the earlier subclauses that give definitions of terms 

9 and explain concepts more precisely. 

10 Developers of profiles that are not formal POSIX Standardized Profiles (POSIX SPs) 

n should read all of Section 6 . 

12 Developers of profiles that are formal POSIX SPs should read all of Section 6 and 

13 Annex A. 


14 6.1 Scope 

is The information presented here about profiles is limited in scope to assist those 

16 needing to understand profile concepts as they apply to the POSIX Open System 

17 Environment. Covered are profiles constructed from standards (and profiles) 

18 listed within this guide (that, by design, are consistent with POSIX.l). 

19 The goal is to create a co mm on approach and documentation scope and style for 

20 POSIX-oriented profiles. Annex A goes further by giving specific guidance to 

21 developers of formal POSIX SPs. 


22 6.2 Profile Concepts 

23 Responsibility: Bob Gambrel 

24 Introduction 

25 This guide is designed to assist in the selection of standards in the procurement 

26 process or as a target application environment. Profiles also assist in the selec- 

27 tion of standards. A profile is a suite of base standards with specified options. 

28 Profiles can be created by software developers to describe the environment they 
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29 target or by buyers to identify their purchasing objectives. 

30 Basic Terminology 

31 E 

32 There are two general classes of standards documents: 

33 — Base standards 

34 — Profiles, including application environment profiles (AEP), standardized E 

35 profiles, and POSIX standardized profiles E 

36 See 2.2.2 for format definitions of these terms. As used in this guide, base stan- e 

37 dards specify functionality, syntax, protocols, data formats, etc., in detail, while e 

38 profiles do not. Instead, profiles (sometimes called “functional standards”) iden- E 

39 tify which base standards are applicable. Since base standards often consist of a e 

40 base or mandatory part and a number of selectable optional parts and values, 

41 profiles may also (or may not) choose, for each base standard, specific options or 

42 values. A profile may also identify other profiles, allowing the construction of 

43 “larger” profiles based on both base standards and other “smaller” profiles. 

44 NOTE: In the context of internationalization, the term “national profile” is frequently used and will E 

45 be found, for example, in POSIX. 1 {2} and POSIX.2. Its meaning is consistent with the definitions in 

46 2.2.2, but in many cases such profiles reflect national cultural conventions. For example, Denmark 

47 and Japan both have specified a national character profile. 


48 6.2.1 Relationships Between This Guide and Profiles 

49 Key to the understanding of profiles is a discussion of the relationships that exist 

50 among profiles, this guide, and the base standards. 

51 There exist many thousands of base standards, each addressing a particular, usu- 

52 ally narrowly scoped, area of application portability or interoperability. Many of 

53 the base standards, developed over the years, are simultaneously narrow in scope 

54 (for example, a C binding of SQL), but broadly applicable (for example, applicable 

55 to operating systems that comply with POSIX specifications and those that do not.) E 

56 The base standards listed in 1.2 form the basis of the POSIX Open System 

57 Environment. The list is comprehensive, in that its coverage is broad enough to 

58 cover most modern day application development, and the base standards selected 

59 have been determined to be consistent with POSIX. 1 {2}. 

60 While this guide does not list all base standards, it is still a large list, and in fact 

61 the list contains base standards that might not be consistent with each other 

62 (choose any two standards from the POSIX OSE and they might not be consistent 

63 with each other.) The process of profile writing addresses this. 

64 The profile writer reduces even further the list of base standards to just the (rela- 

65 tively) few that are needed to provide portability and interoperability in a given 

66 functional area. In the process, the profile writer grapples with the coherence of 

67 the selected base standards by choosing only those that will work together to get 
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68 the particular job done. Profile writers should also deal with harmonization , 3) 

69 which means making the profiles consistent with each other where they overlap. 

70 This can often be done among profiles even where the functional areas served 

71 differ greatly. Procurements specifying two profiles that have been harmonized 

72 by their authors have the benefit of knowing that the two will not conflict with 

73 each other. 

74 By specifying compliance to a particular profile in a procurement, a consumer 

75 easily references a set of multiple base standards that have been determined to: 

76 serve a particular purpose and work together. E 

77 The benefits and relationships do not end here, however. Since profiles can be 

78 constructed to reference profiles as well as base standards, future profile writing 

79 will be even easier. 

80 NOTE: An analogy is in the construction of electronic equipment such as computers. The basic 

81 building blocks are “components,” such as memory chips and capacitors, which can be fabricated into 

82 larger building blocks such as printed circuit boards, which can be fabricated (with other com- 

83 ponents or printed circuit boards) into larger building blocks, such as standalone computers, which 

84 can be fabricated into larger building blocks such as department wide networks of computers, etc. 

85 Likewise, a few base standards (the basic building blocks), can be gathered together into “com- 

86 ponent” profiles, which can then be gathered together (with other base standards or component 

87 profiles) into larger “platform” profiles, which can be gathered together into larger “application area” 

88 profiles. (See 6.3.3.5.) 

89 The development of profiles from the primary building blocks (base standards) 

90 results in larger building blocks (profiles) that can then be incorporated into 

91 future profiles and also into future versions of this guide. 

92 The Importance Of Profiles 

93 Profiles are important for a number of reasons: 

94 — Profiles select one or more base standards or profiles and specify options 

95 and parameters within these. This provides a clear statement of 

96 specifications that describe the standards for the target functional 

97 objective(s). 

98 — Profiles include information about the relationship between the standards 

99 included (i.e., coherency is an objective). 

100 — Profiles are a clear method of communication about the specific standards 

101 needed for an application domain and can be used in procurement, in con- 

102 formance testing, and as a target for applications development. 


103 3) This should not be confused with international harmonization, which refers to a specific process 

104 that must be followed in the approval process for International Standardized Profiles (ISPs). 
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105 6.3 Guidance to Profile Writers 

106 Responsibility: Bob Gambrel 

107 This clause expands the concept of profiling in the manner needed by profile writ- 

108 ers and provides detailed guidance to those writers. It includes a description of 

109 the basis for this guidance, expands on the purposes served by profiles, and 

no finishes with more detailed guidance specifically aimed at those writing profiles. 

in Using this guide as a basis, profile writers can develop their own informal 
H2 profiles, suited to their own needs, or formal standards bodies can develop formal, 

113 balloted profiles. This clause details the requirements that should be met by 

114 developers of profiles whether they are POSIX SPs, standardized profiles, or less 

115 formal profiles. Standardized profiles are formal profiles that meet the require- 

116 ments of a sponsoring standards body. Standardized profiles that also meet the 

117 requirements for POSIX-based profiles (rules established by IEEE) are called 

118 POSIX standardized profiles (POSIX SPs.) For more information about writing 

119 POSIX SPs, see Annex A. 

120 Note to reviewers: Annex A has important information in relation to this section 

121 that should be reviewed. 

122 6.3.1 Basis for This Guidance 

123 Many of the ideas and concepts for profiling described in this section derive from 

124 the work of ISO/IEC JTC 1 SGFS as documented in ISO/IEC TR 10000-1. Some 

125 items specified in that document that are not covered here include: 

126 — International standardization considerations 

127 — Conformance issues 

128 — Processes and procedures 

129 — Maintenance 

130 — Taxonomy 

131 Additionally, some consideration was given in this guidance above and beyond 

132 that given in ISO/IEC TR 10000: 

133 — Standardized profiles and POSIX standardized profiles as a conceptual 

134 extension to International Standardized Profiles (ISP). 

135 — IEEE basis, not ISO basis, for formatting rules; see Annex A. 

136 Writers of profiles following the guidance of this clause should refer to Annex A if 

137 they intend to propose IEEE acceptance as a POSIX SP and to ISO/IEC TR 10000 if 

138 they intend to propose acceptance as an ISP. 
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139 6.3.2 Purpose of Profiles 

140 Profiles define combinations of base standards and profiles for the purpose of: 

141 — Identifying the base standards, together with appropriate classes, subsets, 

142 options, and parameters, that are necessary to accomplish identified func- 

143 tions for purposes such as interoperability and portability. 

144 — Providing a system of referencing the various uses of base standards that is 

145 meaningful to both users and suppliers 

146 — Enhancing the availability for procurement of consistent implementations 

147 of functionally defined groups of base standards that are expected to be the 

148 major components of real application systems 

149 — Promoting uniformity in the development of conformance tests for systems 

iso that implement the functions associated with the profiles 

151 6.3.3 Detailed Guidance to Profile Writers 

152 6.3.3.1 The Relationship to Base Standards 

153 Base standards specify procedures and formats that facilitate application porta- 

154 bility and interoperability. They provide options, anticipating the needs of a 

155 variety of applications and taking into account different capabilities of real sys- 

156 terns and networks. 

157 Profiles further promote portability and interoperability by defining how to use a 

158 combination of base standards for a given function or application area. Profiles, 

159 by definition, do not define new application interfaces. 

160 In addition to the selection of base standards, a choice may be made of permitted 

161 options for each base standard and of suitable values for parameters left 

162 unspecified in the base standard. 

163 Profiles should not contradict base standards, but should make specific choices 

164 where options and ranges of values are available. Profiles must include all of the 

165 items made “mandatory” by the standard. The choice of the base standard 

166 options should be restricted so as to maximize the probability of interworking 

167 between systems implementing different selections of such profile options, con- 

168 sistent with achieving the objectives of the profile. 

169 A profile makes explicit the relationships between a set of base standards used 

170 together (relationships that are implicit in the definitions of the Base Documents 

171 themselves) and may also specify particular details of each base standard being 

172 used. 

173 A profile may contain conformance requirements that are more specific and lim- 

174 ited in scope than those of the base standards to which it refers. While the capa- 

175 bilities and behavior specified in a profile will always be valid in terms of the Base 

176 Documents, a profile may exclude some valid optional capabilities and optional 

177 behavior permitted in those base standards. 
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178 Thus, conformance to a profile implies, by definition, conformance to the set of 

179 base standards that it references. However, conformance to that set of Base 
iso Documents does not necessarily imply conformance to the profile. 

181 6.3.3.2 Main Elements of a Profile Definition Document 

182 The definition of a profile should comprise the following elements: 

183 — A concise definition of the scope of the function for which the profile is 

184 created and of its purpose 

185 — Reference to a set of base standards and other profiles, including precise 

186 identification of the actual texts of the base standards and profiles being 

187 used and of any approved amendments and technical errata, conformance 

188 to which is identified as potentially having an impact on achieving portabil- 

189 ity and interoperation using the profile 

190 — Specifications of the application of each referenced base standard and 

191 profile, covering recommendations on the choice of classes or subsets and on 

192 the selection of options, ranges of parameter values, etc. 

193 — A statement defining the requirements to be observed by systems claiming 

194 conformance to this profile, including any remaining permitted options of 

195 the referenced base standards and profiles, which thus become options of 

196 this profile 

197 Systems that interoperate can perform different but complementary roles (e.g., an 

198 initiator-responder or a master-slave relationship). In such a situation the profile 

199 should identify the separate roles that may be adopted by a system, and these 

200 should be stated as either mandatory requirements or options of the profile, as 

201 appropriate. 

202 6.3.3.3 Profile Objectives 

203 Completeness 

204 A profile should be complete with respect to its functionality objectives. This may 

205 well be an iterative process, since the understanding of the requirements and 

206 standards will evolve. Completeness means that all areas where standards 

207 should be applied have been identified and the requirements defined. Where 

208 standards exist, they have been included, and the options within those standards 

209 have been addressed. Where standards do not exist, but are needed, this has 

210 been documented in the profile. 

2 11 It may be appropriate to document (probably in a nonnormative appendix) 

212 specifications and alternatives available in areas where standards have not been 

213 defined. The meaning of this concept will be relative to the forum for acceptance 

214 of the profile. If the profile is targeted at ISO acceptance, then ISO DIS and IS 

215 standards should be the reference point, where as a US Government profile might 

216 be focused on FIPS and ANSI standards. Within private industry, consortium and 

217 even vendor specific specifications could be incorporated, keeping these as 
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218 examples and not explicit requirements, which will simplify harmonization with 

219 formal standards as they emerge. Where standardized profiles are being 

220 developed and gaps are identified, the profile writer should identify the require- 

221 ments that are not satisfied by a standard. If there is a preliminary specification 

222 available that addresses many of the requirements, that specification should be 

223 referred to informatively. 

224 Clear Communications 

225 A key objective for the profile is clear communications between the affected par- 

226 ties. Users, software developers, and platform suppliers all need to have the 

227 same terms and specifications. The application software developers and system 

228 vendors need a common set of specifications to target for their development 

229 efforts. 

230 Harmonization 

231 Harmonization^ means making the profiles consistent with each other where they 

232 overlap. This can often be done among profiles even where the functional areas 

233 served differ greatly. This assures that the maximum practical agreement exists 

234 between different profiles, maximizing the implementations of that common 

235 ground. 

236 Validation 

237 A profile addresses validation in two different ways. 

238 Firstly, by selecting options and parameters within the profile, validation is 

239 potentially made simpler. 

240 Secondly, by including more than one base standard, validation potentially 

241 becomes more difficult. Now validation extends beyond just insuring a single 

242 standard is being complied with into the area of insuring that the interactions 

243 between and among multiple base standards is also being complied with. 

244 Coherence 

245 The simple selection of a group of standards does not assure that they will work 

246 together on a platform in a predictable way. A profile should contain a matrix of 

247 all standard components compared to each other and state what relationship 

248 exists between them. A profile may be coherent if it states that between two stan- 

249 dards no relationship needs to exist, that none shall exist, or that a specified rela- 

250 tion shall exist. Not to speak to an intersection in the matrix would indicate that 

251 the issue of coherence has not been addressed. 


252 4) Refer to the earlier footnote on international harmonization. E 
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253 Gap Identification 

254 In the process of developing profiles, there may be gaps in coverage by standards 

255 that become apparent. These may exist in terms of the characteristics available 

256 with one standard that need to be made available from another, or missing stan- 

257 dards, or additional functionality that is needed for a specific applications 

258 activity. So, an additional objective for a profile effort is to document the require- 

259 ments for such additional work and forward it to the appropriate standards effort. 

260 Profile groups in industry should consider providing expertise to the associated 

26 1 standards groups to assure that the resulting standards meet the needs of that 

262 applications area. 


265 6.3.3.5 Types of Profiles 

266 Three different types of profiles have been, or are being, defined by the procedures 

267 described above: 

268 — Component Profiles 

269 — Application Area Profiles 

270 — Platform Profiles 

271 A Component profile is mostly a subset of a single standard. The profile develop- 

272 ers specify mandatory options for a specific domain, options that are not desirable 

273 for that domain, gaps in that parent standard, and, if necessary, specifications to 

274 fill that gap. Examples of such profiles are MAP, TOP, and GOSIP profiles and pos- 

275 sibly the POSIX. 13 embedded realtime POSIX profile if it continues to be based 

276 exclusively on functions chosen from the POSIX.4 realtime standard. 

277 An Application Area Profile is created from multiple standards that specify multi- 

278 pie, diverse types of functionality needed for a particular application area (e.g., 

279 database, networking, graphics, operating system). The application area profile 

280 developers specify all the diverse standards necessary for the application area in 

281 question. Within each standard, they identify mandatory options, functions and 

282 options that are not needed, gaps in the standards, and, if necessary, 

283 specifications to fill the gaps. Examples of application area profiles are the 

284 POSIX. 10 supercomputing and POSIX.il transaction processing profiles. 

285 A Platform Profile focuses on the functionality and interfaces needed for a partic- 

286 ular type of platform. The platforms could be traditional platforms (such as time 

287 sharing systems) or relatively new or emerging platforms (e.g., workstations, per- 

288 sonal computers, or symmetric multiprocessing systems). A platform profile could 

289 be created from one or multiple diverse standards. As with other types of profiles, 

290 the profile developers have to specify the standards, options, standards gaps, and 

291 if necessary, specifications to fill the gaps. Examples of platform profiles are the 

292 POSIX. 18 Platform Profile for Traditional Multiuser UNIX systems and the 
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293 POSIX.14 Multiprocessing profile. 

294 All three types of profiles can be seen in the next section. 
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Section 7: POSIX SP Profiling Efforts 


i Responsibility: Wendy Rauch 


2 7.1 Introduction 

3 This section maintains the list of currently known POSIX Standardized Profiles 

4 (POSIX SPs). This list is a factual record of which POSIX SPs exist, or are in 

5 preparation, together with a summary description of the scope, scenario, and 

6 model for each profile. These POSIX SPs might be useful as building blocks for 

7 other profiles. 


8 7.1.1 Approved POSIX Standardized Profiles 

9 There are currently no approved POSIX SPs. 


10 7.1.2 POSIX Standardized Profiles In-Progress 

11 The current efforts to develop POSIX SPs are summarized in Table 7-1. E 


12 7.2 General Purpose POSIX SPs 


13 7.2.1 POSIX Platform Environment Profile E 

14 7.2.1.1 Rationale and Overview 

is The POSIX Platform Environment Profile, IEEE POSIX. 18, is a platform profile E 

16 based on POSIX. 1 {2} and related standards. It defines the functionality and stan- 

17 dards needed for a system that is as similar as possible to the traditional UNIX 

18 operating system’s interactive, multiuser development and run-time environment. 

19 The platform profile is valuable for many users, vendors, programmers, and pro- E 

20 curement officers who do not have the time or desire to analyze and specify all the 

21 individual interfaces for a system they need. The platform profile obviates this E 

22 analysis by enabling the users to point to a single document that specifies exactly 

23 what they should order to obtain a system that looks like traditional UNIX sys- 

24 terns, except that the POSIX platform profile will be totally based on formal e 
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25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 


Table 7-1 - POSIX SPs In Progress 


^NamtT Taxonomy Profile Name Profile Type 

E 
E 
E 
E 
E 

NOTES: 

(1) At this time it is not known whether the three realtime profiles will be contained within a 
single multipart POSIX SP, or separate single-part POSIX SPs. 

(2) While the issue of a taxonomy for POSIX SPs has not been decided, a placeholder has been 
provided and a proposed taxonomical name for one profile has been listed. 


IEEE 

IEEE 

IEEE 

IEEE 

IEEE 

IEEE 

IEEE 


P1003.10 

P1003.ll 

P1003.13 

P1003.13 

P1003.13 

P1003.14 

P1003.18 


USI-P001 


Supercomputing 
Transaction Processing 
Realtime, Multipurpose Systems 
Realtime Embedded Control System 
Realtime Intermediate 
Multiprocessing Application Support 
POSIX Platform Environment Profile 


Application area profile 
Application area profile 
Application area profile 
Application area profile 
Application area profile 
Platform profile 
Platform profile 


42 standards. E 

43 7.2.1.2 Content of the Platform Environment Profile 

44 The POSIX Platform Environment Profile consists of: 

45 — ISO/IEC 9945-1, with a selection of options and definitions of parameters; E 

46 — All of the POSIX.2 (Shell and Utilities) and, optionally, POSIX.2a (User Por- E 

47 tability Extension); and E 

48 — At least one of the following languages: ISO C, Ada, or FORTRAN. E 


49 To reflect the goals and intent of the POSIX. 18 working group, the POSIX platform E 

50 profile document also commits to specifying additional specifications in the future, E 

51 when those specifications are completed and approved as standards. These 

52 specifications include system administration, secure/trusted systems extensions, 

53 realtime facilities, verification testing facilities, Ada and FORTRAN language 

54 bindings, graphical user interfaces, and network interface facilities. 

55 The POSIX platform profile is expected to be the pioneer Application Environment E 

56 Profile submitted to ISO for international approval. The concept of Application 

57 Environment Profiles and Platform Profiles is new. How ISO handles the interna- 

58 tional standardization of the POSIX platform profile, and the profile issues E 

59 resolved, will likely set a precedent followed in the development of other profile 

60 standards. 
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61 7.2.2 Multiprocessing Systems Platform Profiles 

62 7.2.2.1 Rationale and Overview 

63 The POSIX Multiprocessing Systems Profile (IEEE POSIX.14) is a platform profile. 

64 Like the POSIX PEP (POSIX. 18), the Multiprocessing Systems profile defines the 

65 functionality, standards, and options within standards that are needed for 

66 development and execution on a multiprocessing platform. 

67 The Multiprocessing Systems profile is intended for use by multiprocessor ven- 

68 dors, application developers, users, and system administrators. It is important 

69 because it is designed to support portability of multiprocessing applications, as 

70 well as users and system administrators in multiprocessing environments. 

71 The Multiprocessing Systems Profile has two major goals. The first one is to 

72 make POSIX safe for multiprocessing. This goal requires the POSIX.14 working 

73 group to identify and address the caveats, problems, and failings of POSIX base 

74 standards for multiprocessing platforms. Examples of these failings range from 

75 reentrant-function problems to potential problems with threads. 

76 The second goal is to make POSIX useful for multiprocessing. This goal requires 

77 the POSIX.14 working group to ensure that POSIX supports the functionality 

78 needed by multiprocessing platforms. An example of this is ensuring that POSIX 

79 has capabilities to allow vendors to parallelize software functions. In the absence 

80 of parallelizing standards, the details of what happens when the same software 

81 functions are used on different multiprocessor system vary. 

82 7.2.2.2 Content of the Multiprocessing Systems Profile 

83 The Multiprocessing Systems platform profile identifies standards, options, and 

84 gaps in the standards relevant to multiprocessing. It also identifies additional 

85 requirements not satisfied by existing standards and, in an informative annex, 

86 suggests interfaces to extended services that can satisfy some of these require- 

87 ments. In addition, the POSIX.14 Multiprocessing Systems Group will propose 

88 changes and amendments to a variety of relevant standards in order to encourage 

89 the specifiers of these standards to add functions and options that accommodate 

90 multiprocessing requirements. 

91 Standards particularly relevant to the Multiprocessing System Profile include the 

92 POSIX Pthreads extension (IEEE POSIX.4a), the supercomputing batch scheduling 

93 standard (IEEE POSIX. 15), and the supercomputing proposed checkpoint and res- 

94 tart facilities (IEEE POSIX. 10). Since checkpoint and restart facilities will be 

95 added to the POSIX. 1 {2} standard, POSIX. 1 {2} is also of concern to the Multipro- 

96 cessing Profile. 

97 The Multiprocessing Systems profile will specify both general-purpose-computing 

98 and multiprocessor-specific standards. General-purpose standards planned or 

99 under consideration for the Multiprocessing Systems profile include: 

100 — The IEEE POSIX.1 core POSIX system, POSIX.2 POSIX Shell and Utilities, 

101 and POSIX.2a User Portability Extension; 
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102 — The IEEE POSIX.4 realtime extension; 

103 — The IEEE POSIX.4a: POSIX Pthreads extension; 

104 — The IEEE POSIX.6 POSIX security standard and POSIX.7 system administra- 

105 tion standard; 

106 — The Ada language bindings (IEEE POSIX.5) and FORTRAN language bind- 

107 ings (IEEE POSIX.9) to POSIX; 

108 — The IEEE POSIX. 10 Supercomputing Profile, POSIX.il Transaction Process- 

109 ing Profile, and POSIX.13 Realtime Applications Profiles. 

110 As other standards emerge, they too will be incorporated in the Multiprocessing 

111 Systems profile. An annex of this document will deal with, and list, relevant 

112 emerging standards to provide an idea of the Multiprocessing Systems profile’s 

113 direction. 

114 Multiprocessing-specific requirements identified by the POSIX.14 Multiprocessing 

115 working group include: 

116 — System administration tools for multiprocessors; 

117 — Parallelizing compilers; 

118 — Explicit parallelism; 

119 — Threads; 

120 — Thread-safe libraries; 

121 — Message-passing IPC; 

122 — Parallel utilities (e.g., find, grep, make, etc.); 

123 — Scheduler controls; 

124 — Processor allocation: mandatory/advisory; 

125 — Processor binding; 

126 — Degree of symmetry: I/O, computation, memory. 

127 Standards will be needed for many of these requirements. Many of these require- 

128 ments will, therefore, become the subject of a POSIX.14 working group proposal 

129 for a new standardized function or an option in other standards. 

130 7.2.3 Supercomputing 

131 7.2.3.1 Rationale and Overview 

132 The Supercomputing Application Environment Profile (IEEE POSIX. 10) is a profile 

133 designed to support application and programmer portability in POSIX-based 

134 supercomputer environments. The profile’s goal is to allow supercomputer appli- 

135 cation code to be ported to other sites, reduce the learning curve of users, and 

136 encourage production of timely third-party applications. 
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137 The need exists for such a profile because of the differences between supercomput- 

138 ing environments and traditional application environments. One difference is 

139 that supercomputing jobs are computationally intensive, very long running, and 

140 very demanding of resources. Another is that the cost of the supercomputer CPU 

141 and many of its peripheral resources is extremely high. 

142 Ordinary POSIX standards are not applicable in their entirety to supercomputer 

143 environments because the traditional UNIX-based POSIX functions are not ade- 

144 quate to meaningfully manage the use of, and accounting for, a supercomputer or 

145 its resources. Furthermore, supercomputers need much better tape handling, 

146 multiprocessing, and other capabilities than POSIX or UNIX specifications 

147 presently support. 

148 7.2.3.2 Content of the Supercomputing Profile 

149 The Supercomputing Application Environment Profile identifies POSIX base stan- 

150 dards and other relevant standards that support supercomputing requirements. 

151 Where none exist, the POSIX. 10 working group will define the functionality itself, 

152 or instigate the formation of a new group to define it. In addition, the POSIX. 10 

153 working group is taking some of the traditional modifications built to allow UNIX 

154 systems to run on supercomputers, and making those modifications both con- 

155 sistent across supercomputers and portable to users, system administrators, and 

156 applications. 

157 Base computing standards specified by the supercomputing profile (or planned for 

158 specification when the standards are completed) include: 

159 — The IEEE POSIX. 1 {2} core POSIX system, POSIX.2 POSIX Shell and Tools, 

160 and POSIX.2a User Portability Extensions (and the corresponding FIPS 

161 standards); 

162 — The IEEE POSIX.4 realtime work (particularly the use of its asynchronous 

163 I/O facility); 

164 — The IEEE POSIX.6 POSIX security standard and POSIX.7 system administra- 

165 tion standard; 

166 — Several graphics standards, including ISO GKS, PHIGS, and CGM, ANSI 

167 IGES, and the X Consortium’s PEX. 

168 — X3H2.6 (also called Xll) for windowing; 

169 — Several programming languages, including ISO, ANSI, and the NIST’s FIPS 

170 for C, FORTRAN-77, Pascal, Ada, Common LISP, and COBOL. 

171 — TCP/IP protocol stacks and network applications (e.g., file transfer and mes- 

172 saging) now and OSI in the long-term; 

173 — The IEEE POSIX.8 Transparent File Access standard for distributed file 

174 management; 

175 — The X3T5.5 Remote Procedure Call (RPC). 
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176 The nonstandardized and nonavailable supercomputing functions identified in the 

177 POSIX.10 profile include: 

178 — Batch system scheduling, administration, and network definition; 

179 — Checkpoint recovery; 

iso — A resource manager; 

181 — A better tape management facility; 

182 — Better mass storage/archiving facilities. 

183 There are no existing standards for batch scheduling and administration facili- 

184 ties. Batch scheduling and administration extensions to POSIX base standards 

185 are currently being defined by the IEEE POSIX. 15 working group—a group 

186 spawned by the Supercomputing profile working group. 

187 To meet recovery and archiving requirements, the POSIX.10 working group 

188 defined system interfaces for functions that perform “checkpoint,” “restart,” and 

189 better magnetic tape handling (e.g., to rewind a tape under program control). 

190 These interfaces have been submitted to the POSIX. 1 working group for inclusion 

191 in the next POSIX. 1 {2} revision. 

192 7.2.4 Transaction Processing 

193 7.2.4.1 Rationale and Overview 

194 The Transaction Processing Application Environment Profile (IEEE 1003.11) is 

195 intended to support the development of portable online transaction processing 

196 (OLTP) applications in POSIX environments. This profile is targeted at application 

197 developers and open system services suppliers. It is important because transac¬ 
ts tion processing is a major area of business for most large computer vendors and it 

199 plays a major role in the daily operations of most users. There are currently no 

200 existing POSIX functions that specifically address OLTP needs. 

201 7.2.4.2 Content of the Transaction Processing Profile 

202 The Transaction Processing profile’s goal is to identify the interfaces and stan- 

203 dards relevant to OLTP, and optional functions in existing standards that must be 

204 made mandatory for OLTP applications. The profile will specify general-purpose 

205 standards, as well as standards unique to OLTP. 

206 The Transaction Processing Profile’s specifications include or plan the following 

207 generic and transaction processing-specific standards: 

208 — The ISO/IEC 9945-1: 1990 (POSIX 1003.1) core POSIX system interfaces 

209 (including required options, minimum values for certain variables, and par- 

210 ticular environment variables needed for OLTP applications); 

211 — The IEEE 1003.2 Shell and Utilities’ software development utilities option, 

212 C language development utilities option, and C language bindings option; 
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213 — The IEEE 1003.2 getconf utility; 

214 — The realtime files and asynchronous input and output features from the 

215 IEEE 1003.4 Realtime POSIX Extensions; 

216 — The IEEE 1003.6 POSIX security standard; 

217 — The ISO/IEC, ANSI, and FIPS C and COBOL programming languages; 

218 — TCP/IP networking in the short term and OSI in the long-term; 

219 — The X3T5.5 Remote Procedure Call (RPC) 

220 — The ISO SQL database language; 

221 — The ISO Distributed Transaction Processing 10026.1, .2, and .3 for com- 

222 munication of transaction information. 

223 The Transaction Processing profile also identifies extensions needed to existing 

224 standards to support distributed transaction processing. Important extensions 

225 that need to be defined include those related to the two-phase commit, as well as 

226 others related to making RPCs robust. 

227 The P1003.ll working group is working with the ISO RPC Group to add transac- 

228 tion semantics to the Networking working group’s RPC specifications. These 

229 extensions will be incorporated in the Transaction Processing profile. Plans are 

230 also for the 1003.11 profile to draw on the transaction processing work being pro- 

231 duced by the X/Open consortium, particularly on the XA interfaces (the interface 

232 between a Transaction Manager and a Resource Manager). 

233 7.2.5 Realtime Application Profiles 

234 7.2.5.1 Rationale and Overview 

235 Different types of realtime applications have different characteristics and diverse 

236 requirements. For example, embedded systems generally do not need the full 

237 functionality of an operating system, nor do they require all the IEEE POSIX.4 

238 realtime extensions. Compliance with the entire realtime standard and/or POSIX 

239 operating system interfaces could reduce the embedded system’s responsiveness 

240 and increase the amount of memory needed for systems that need to be embedded 

241 in limited space. High-end realtime systems, on the other hand, have softer real- 

242 time requirements. However, they need the full operating system and realtime 

243 functionality. 

244 Therefore, the POSIX. 13 working group was formed to define profiles for various 

245 types of realtime applications. The realtime profiles defined will determine which 

246 interfaces must be implemented for a given type of realtime system to claim con- 

247 formance to the realtime standard. 
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248 7.2.5.2 Targeted Realtime Application Profiles E 

249 The POSIX. 13 working group is defining profiles to address several types of real- E 

250 time applications. These include: E 

251 — Low-end, embedded systems (often known as “hard” realtime systems); 

252 — Mid-range realtime systems with medium-level critical realtime con- 

253 straints; 

254 — High-end realtime systems. 

255 7.2.5.2.1 Embedded Realtime Systems E 


256 Embedded realtime systems are typically standalone systems used for robot con- 

257 trollers, automated systems controllers, instrumentation, high-speed data acquisi- 

258 tion, satellite subsystem control, flight control, some process control, and some E 

259 testing. Time-critical responsiveness is a key requirement of embedded systems. 

260 In the absence of a standard, the realtime functionality required for embedded 

261 systems is generally provided by a proprietary realtime kernel or a simple home- 

262 grown monitor using memory mapped I/O. 

263 Since low-end embedded systems need only mi nim al functionality, the POSIX. 13 

264 working group will select a relatively small number of POSIX.4 and POSIX. 1 {2} 

265 functions that will be required for portable realtime embedded systems. These 

266 functions will be selected for several types of embedded applications. e 

267 One type of embedded application is a minimal system, usually buried deeply in e 

268 the overall system electronics. Such minimal applications have no requirements E 

269 for a file system, multiple processes, or I/O via specific device drivers. The E 

270 minimal realtime profile, however, will specify the POSIX.4a threads extension to E 


271 support multiple flows of control. E 

272 The second type of embedded application is often used in control systems. Real- E 

273 time controller applications require a file system and threads, but not multiple E 

274 processes. e 

275 7.2.5.2.2 Mid-Range Realtime Applications E 


276 Mid-range or intermediate-level realtime profiles are targeted at compute- e 

277 oriented applications that are typically used in avionics, radar systems, subma- e 

278 rines, and medical imaging equipment, as well as controllers that control a group E 

279 of robots or a subsystem on the factory floor. These applications tend to run on E 

280 platforms that are dedicated to a single application set or mission mode. e 

281 The design complexity of such dedicated realtime applications varies from simple E 

282 to complex to accommodate a range of requirements. Such requirements may E 

283 include sophisticated signal processing capabilities, but do not necessarily include E 

284 a file system. A profile that satisfies these requirements would likely specify most E 

285 of the POSIX.4 functionality (except for file system facilities), along with relevant E 

286 options from the POSIX.4 and POSIX. 1 {2} standards and the POSIX.4a threads E 

287 extension. E 
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288 7.2.5.2.3 High-End Realtime Applications E 

289 High-end realtime applications are applicable to complex, multipurpose realtime e 

290 systems. Such multipurpose realtime systems typically are used in military com- E 

291 mand and control, in space station control systems, in systems that control robot E 

292 or factory subsystems, as the operating system for high-end simulation systems, E 

293 and at high-functionality realtime application that are paced by operator interac- E 

294 tion. E 

295 The current realtime, multipurpose profile is geared to full-function realtime sys- E 

296 terns such as simulation applications and embodies most of the existing practice E 

297 in the simulator world. Since simulation systems have a greater design complex- E 

298 ity than embedded or mid-range systems, and need much greater functionality, E 

299 the multipurpose realtime profile will most likely require all or most of the E 

300 POSIX.4 and POSIX.1 {2} standards. This profile does not require threads. It does, E 

301 however, specify the XI1 window system as the basis for a human-computer inter- E 

302 face. e 
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Annex A 

(informative) 

Considerations for Developers of POSIX SPs 


1 A.1 Introduction 

2 Responsibility: Bob Gambrel 

3 The contents of this Annex are illustrative of rules that might be developed for 

4 the submitters of POSIX Standardized Profiles (SPs). 

5 This Annex contains modifications and comments relating to the use of the TCOS- 

6 SSC POSIX Standards Style Guide {B6} in POSIX SPs. 


7 A.2 Scope 

8 While Section 6 addressed profiles generally, this Annex addresses considerations 

9 for developers of formal POSIX Standardized Profiles. It builds directly upon the 

10 concepts, principles, and guidance of Section 6. 

n Note to reviewers: This Annex is not complete, in that more work is required in the 

12 domain of POSIX profiles. 

13 Future work in the area of profiling will be done by IEEE and the standards com- 

14 munity. This document, and the guidance it provides, will be updated as 
is appropriate. The major areas expected to be addressed are: 

16 — International standardization considerations 

17 — Conformance issues 

18 — Taxonomy of POSIX SPs 

19 — Registration of POSIX SPs 

20 — Delegation of authority to call something a POSIX SP (Note: Currently, this 

21 document does not prohibit another group beside IEEE from calling their 

22 document a POSIX SP.) 

23 — Clarification of base standards referencing issues such as subsetting and the 

24 handling of options 

25 — Editorial issues such as guidance on the correct level of detail 


A.2 Scope 
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26 — Additional guidance on referencing base standards and “standards in pro- 

21 gress” 


28 A.3 The Role of POSIX SPs 

29 In 6.3.3.5, a classification scheme was given for profiles in which three different 

30 “types” were identified. That scheme is based, essentially, on the scope covered 

31 by the profile. Another useful classification scheme, based on scope and on who 

32 develops the profiles, is presented in this annex. 

33 Figure A-l shows these classes of profiles and the relationships between them and 

34 base standards. 

35 _ 


POSIX-Based Standards and Profiles 


r - n 



36 _ 

37 Figure A-1 - Universe of Profiles and Standards 

38 Base standards cover a universe of diverse needs. POSIX base standards (e.g., 

39 POSIX. 1 {2}, P1003.4, ...) cover a narrower set of needs related to “POSIX.” In the 

40 figure, the POSIX base standards are shown as a small subset of the larger world 

41 of base standards. 

42 At the other end of the spectrum, organization-specific (e.g., company-specific) 

43 profiles are large in number and range even more widely in their coverage. 

44 (There are many more organizations procuring systems, and effectively writing 

45 profiles, than there are committees writing standards.) 

46 Industry-specific profiles are based on specific industry needs. From the point of 

47 view of the organization-specific profile writer, industry specific profiles are 
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48 applicable to many organizations (in the same industry), and hence are possibly 

49 not precisely what any specific individual organization needs. They address the 

so broad consensus of the industry, from which there is usually deviation when you 

51 look at individual organizations whose needs range further. 

52 Standardized Profiles are formal balloted documents. POSIX SPs are the subset of 

53 standardized profiles that pertain to the POSIX base standards. While not limited 

54 to just POSIX base standards, POSIX SPs nonetheless provide a distinctly POSIX- 

55 oriented view of the base standards. 

56 An organization wishing to procure a “POSIX” based system, then, could first 

57 develop its own organization-specific profile, which it could base on POSIX- 

58 oriented industry-specific profiles (if available), which in turn could be based on 

59 POSIX SPs, which of course are based on the various POSIX base standards. 

60 POSIX SPs provide an industry-neutral building block for creating industry 

61 specific profiles. The developers of POSIX SPs do not have to have knowledge of 

62 any particular industry. They furthermore help ensure coherence among the 

63 many base standards referenced, particularly among the various POSIX base stan- 

64 dards. As such, probably, most POSIX SPs will be created by the IEEE POSIX 

65 working groups meeting concurrently with IEEE POSIX base standards working 

66 groups. Meeting concurrently at the same place helps ensure the coherence of the 

67 base standards and the harmony among the POSIX SPs. 


68 A.4 Special Rules for POSIX SPs 


69 While no rules have yet been developed by IEEE for POSIX SPs, the remainder of 

70 this annex gives examples of what such rules might say and identifies some issues 

71 for which rules might be drafted. 


72 The following criteria for calling a profile a POSIX SP were developed according to 

73 some general principles that have the aim of giving definite value to the word 

74 “POSIX” when used with regards to profiles. The general principles are: 


75 

76 

77 


(1) There is minimum content. Specifically, a POSIX SP must reference some 
part of the suite of POSIX base standards. (Which part specifically is con¬ 
tentious.) 


78 

79 

80 

81 

82 


(2) The POSIX SP must follow a specific approach to conformance (specifically 
the P1003.3.1 test methodology.) 

(3) The POSIX SP must adhere to the POSIX Reference Model. 

(4) There is maximum content; i.e., some consideration must be given to how 
the POSIX SP goes beyond the POSIX OSE as described in this guide. 


83 

84 


(5) Exceptions to the previous principles are expected, requiring a rule- 
making and enforcement body to make those exception decisions. 


85 POSIX SPs are Standardized Profiles that are related to “POSIX.” This subclause 

86 specifies the rules that need to be followed that distinguish POSIX SPs from “Non- 

87 POSIX SPs”. 
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Each POSIX SP is based on, and shall include, one of the following two base stan¬ 
dards sets: 

(1) POSIX. 1 {2} or POSIX.2 (as verified by the P1003.3 methodology), or 

(2) A particular subset of POSIX. 1 {2} and P1003.4 that is being specified for 
a Minimal Realtime profile (as verified by the P1003.3 methodology.) 

Additionally, each POSIX SP adheres to the structure defined by the POSIX OSE 
reference model. 

An approved POSIX SP shall make reference only to base standards identified in 
this guide (1003.0) as being part of the POSIX OSE. Two specific exceptions to this 
general rule are allowed for as described here: 

(1) Reference can be made to required base standards that are clearly out¬ 
side of the scope of the POSIX OSE. Examples of the functionality that 
may require the use of this expedient are: 

— Physical connectors 

— Electrical characteristics 

— Safety requirements 

Such reference to items outside the scope of the POSIX OSE shall be 
justified on a case-by-case basis. It shall be accompanied by details of the 
body responsible for the distribution and maintenance of the referenced 
base standard. 

(2) Reference can be made to required base standards that are being pro¬ 
posed for inclusion in a future version of the guide. Examples of this 
would be specification of a later version of a base standard that is already 
included within the POSIX OSE, or of an additional programming 
language base standard, not yet included within the POSIX OSE. 

In such cases, the POSIX SP should be identified as a POSIX Preliminary 
SP and the specific references should be clearly noted and justified on a 
case by case basis. 

A POSIX Preliminary Standardized Profile (POSIX Preliminary SP) is a POSIX SP 
that satisfies all requirements of a POSIX SP except that it is not a subset of the 
POSIX OSE. [It therefore contains at least one standard or profile that is outside 
the POSIX OSE. It is expected that application would be made to POSIX.O to 
include the standard(s) or profile(s) in the POSIX OSE.] 

A further restriction of POSIX SPs is the necessity to (normatively) reference only 
standards that are recognized by the IEEE. This is limited to IEEE and ISO stan¬ 
dards. 

Approval of a POSIX SP shall not change the status of any documents referenced 
by it. 

The development of a POSIX SP may indicate the need to modify or to add to the 
requirements specified in a base standard. In this case, it is necessary for the 
POSIX SP developer to liaise with the body responsible for that base standard so 
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129 that the required changes may be made through established methods such as 

130 defect reporting, amendment procedures, or the introduction of new work. 


131 A.5 Other Issues 

132 A significant number of issues remain to be addressed concerning the manage- 

133 ment of POSIX SP development. Some of the issues and the concerns are summar- 

134 ized here. 

135 Coherence 

136 The insurance of coherence among the many base standards referenced by a 

137 profile has been found by profile writers to be an onerous task. The profile 

138 writer’s burden could be eased significantly if base standards writers address 

139 coherence at the outset. Specifically, all the P1003.X base standards should be 

140 developed to maximize their coherence. This is seen as a management issue for 

141 TCOS-SEC, the sponsoring body of the P1003.X standards. 

142 Conformance 

143 The development of conformance statements and test methods for profiles is a 

144 significant challenge for profile writers. The challenge is most acute in the area of 

145 conformance of standards that are being developed outside of P1003. A premise 

146 for the profile writing rules associated with conformance must be that the profile 

147 writers are not really experts in the referenced standards. Profile writers (espe- 

148 daily at this early period in their development) must not be overburdened with 

149 untested conformance writing rules. A possible solution is to create a new project 
iso under the auspices of P1003.3 to actually generate new test methods and actually 

151 write the necessary assertions for the first profile. (This approach was used also 

152 for the initial POSIX base standard.) 

153 Base Standards Working Groups 

154 Because profile writers are in some sense the customers of base standards, it is 

155 important for base standards writers to address with priority and urgency the 

156 gaps identified in the development of POSIX SPs. 

157 Scope and Number of POSIX SPs 

158 How many different POSIX SPs are appropriate and how broadly ranging should 

159 be their scope? Should POSIX SPs be rather narrowly focused, spanning just a few 

160 base standards, or should they address a large number of base standards? 
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161 Issues Pertaining to Referencing Base Standards 

162 Many practical writing issues pertain to referencing, for instance, parts of base 

163 standards. This includes not only referencing options, but even the concept of 

164 subsetting, or reducing the functionality of a base standard. Also an issue is how 

165 to reference multiple versions of the same standard (e.g., two different COBOL 

166 standards.) 

167 POSIX SP Procedures and Rules 

168 What does it mean to be a POSIX SP? Rule making for use of the word “POSIX” 

169 must address criteria for such use. Also, many issues remain to be resolved in the 

170 area of ballot procedures. Should IEEE delegate to others the ability to develop 

171 POSIX SPs? If so, should IEEE maintain a registry of such efforts? 


172 A.6 Conformance to a POSIX SP 

173 A POSIX SP must address test methods for itself. In the simplest case, testing the 

174 base standards referenced is sufficient. In more complex cases, additional test 

175 methods will be necessary. In the worst case (if a base standard is subsetted, for 

176 example), the test methods for the base standards may have to be rewritten or 

177 expanded within the POSIX SP. 

178 At the same time, P1003.3 will have to consider revisions to the Test Methods for 

179 Measuring Conformance to POSIX to address test methods for POSIX SPs (e.g., 
iso additional assertion types, minimum requirements for testing POSIX SPs, ...) 


181 A.7 Structure of Documentation for POSIX SPs 

182 This clause gives specific format and content requirements to profile writers who 

183 are developing POSIX SPs. 

184 A.7.1 Principles 

185 The requirements for content and format of POSIX SPs are based on the following 

186 principles: 

187 (1) Profiles shall be directly related to base standards and conformance to 

188 profiles shall imply conformance to base standards. 

189 (2) POSIX SPs shall follow the rules for drafting and presentation of POSIX 

190 SPs detailed here. 

191 (3) POSIX SPs are intended to be concise documents that do not repeat the 

192 text of the base standards. 
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193 (4) Profiles making identical use of particular base documents shall be con- 

194 sistent, down to the level of identical wording in the POSIX SPs for identi- 

195 cal requirements. 

196 A.7.2 Multipart POSIX SPs 

197 Many profiles will be documented and published as individual POSIX SPs. How- 

198 ever, where close relationships exist between two or more profiles, a more 

199 appropriate technique can be used. 

200 Common text between related profiles is essential to ensure consistency, portabil- 

201 ity, and interworking, to avoid unnecessary duplication of text, and to aid writers 

202 and reviewers of POSIX SPs. 

203 A single-part POSIX SP shall not contain the definition of more than one profile. 

204 The following rules apply to multipart POSIX SPs: 

205 (1) A multipart POSIX SP shall contain the definition of a complete profile or 

206 of a related set of profiles. 

207 (2) A part of a multipart POSIX SP may contain a section of the definition of 

208 one or more profiles. 

209 (3) Where a multipart POSIX SP includes more than one profile, the part 

210 structure shall permit each profile to be the subject of a separate ballot; 

211 i.e., its constituent profiles shall be clearly identifiable, and the multipart 

212 structure shall ensure that this can be accomplished. 

213 (4) Wherever possible, the references made from one part to another should 

214 be to complete parts. However, controlled use of one-way references to 

215 sections of other parts is permitted in order to obtain a reasonable mul- 

216 tipart structure. 

217 Because there may also be potential disadvantages from overuse of the multipart 

218 POSIX SP capability, such as difficulties in gaining approval for a complex linked 

219 set of parts, or reduction of the content of a part to a small amount of text, consid- 

220 erable care should be taken with its use. 

221 NOTES: 

222 (1) When a section of text appears in several profiles, possibilities exist for sharing the 

223 corresponding code (etc.) for the implementation of several profiles, and the tests applicable 

224 to the use of the referenced base standards will be applicable to the testing of several 

225 profiles. 

226 (2) It follows that it is in the interest of the implementors to promote the identification of com- 

227 mon sections of text as parts of POSIX SPs, but even more to promote, in future standardiza- 

228 tion and profile work, the use of already defined parts of POSIX SPs, so that profiles fall into 

229 a few “common molds.” In particular, this allows implementation of a part of a POSIX SP 

230 with confidence that it may be used in the implementation of profiles as yet undefined, so 

231 that products are open to future development. 

232 (3) Possibilities exist for a complete profile to be referenced from within the definition of 

233 another profile. 
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234 A.8 Rules for Drafting and Presentation of POSIX SPs 

235 Throughout this Annex, which is concerned with documentation content and lay- 

236 out, reference is made to POSIX SPs. A POSIX SP, or part thereof, may contain a 

237 whole profile definition or part of one or more profile definitions. The wording of 

238 the Annex assumes that it is describing an undivided POSIX SP that defines one 

239 profile in its entirety. Its application to the other cases is easily deduced. Note, 

240 however, that each part of a Multipart POSIX SP shall use the same format as far 

241 as appropriate. 


242 A.8.1 General Arrangement 


243 The elements that together form a POSIX SP are classified into three groups: 


244 

245 

246 


(1) Preliminary elements are those elements that identify the POSIX SP, 
introduce its content, and explain its background, its development, and 
its relationship with other standards and POSIX SPs. 


247 

248 

249 


(2) Normative elements are those elements setting out the provisions with 
which it is necessary to comply in order to be able to claim conformity 
with the POSIX SP. 


250 (3) Supplementary elements are those elements that provide additional 

251 information intended to assist the understanding or use of the POSIX SP. 

252 These groups of elements are described in the following clauses. 


253 A.8.2 Preliminary Elements 

254 A.8.2.1 Foreword 

255 The foreword shall appear in every POSIX SP. It consists of a general part giving 

256 information relating to the organization responsible and a specific part giving as 

257 many of the following as are appropriate: 

258 — An identification of the organization or committee that prepared the POSIX 

259 SP; information regarding the approval of the POSIX SP 

260 — A statement that the POSIX SP cancels or replaces other documents in 

261 whole or in part 

262 — A statement of significant technical changes from the previous edition 

263 — A statement of which annexes are normative and which are informative 

264 A.8.2.2 Introduction 

265 The introduction shall appear in every POSIX SP. It gives specific information 

266 about the process used to draft the POSIX SP and about the degree of international 

267 harmonization that it has received. 
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268 A.8.3 General Normative Elements 

269 A.8.3.1 Title 

270 The title shall be composed of the following three elements: 

271 (1) An introductory element: Standard for Information Technology 

272 (2) An identification element: POSIX Standardized Profile 

273 (3) A main element indicating the subject matter of the POSIX SP. For a 

274 Multipart POSIX SP, this element shall be subdivided into a general title 

275 element common to all parts, and a specific title element for each part; 

276 where necessary, this specific element may include the identifier of an 

277 individual profile. The first word of this element should be the word 

278 “POSIX”. 

279 Example: 

280 Standard for Information Technology — 

281 POSIX Standardized Profile — 

282 POSIX Transaction Processing 

283 A.8.3.2 Scope 

284 This element contains two subclauses as follows: 

285 (1) General 

286 This element shall appear at the beginning of the POSIX SP or POSIX SP 

287 part to define without ambiguity the purpose and subject matter of the 

288 document, thereby indicating the limits of its applicability. It shall not 

289 contain requirements. 

290 (2) Scenario 

291 If the POSIX SP or POSIX SP part defines a profile, it shall include (where 

292 appropriate) the “scenario” of the profile; i.e., an illustration of the 

293 environment within which it is applicable. This may show in a simplified 

294 graphic form how this fits within the POSIX Reference Model. 

295 A profile should first introduce the functional area being addressed and the appli- 

296 cations activities within that area. The requirements that have been addressed 

297 should be delineated, as well as those areas outside of the scope of the profile. 

298 A.8.3.3 Normative References 

299 This element shall give a list of normative documents (base standards), with their 

300 titles and publication dates, to which reference is made in the text in such a way 

301 as to make them indispensable for the application of the POSIX SP. Where pub- 

302 lished amendments or technical errata to base standards are relevant to the 

303 definition of the profile in such a way as to have a potential impact on interwork- 

304 ing or portability, they shall be explicitly referenced here. 
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305 Reference shall also be made to this guide. 

306 A.8.4 Technical Normative Elements 

307 A.8.4.1 Requirements 

308 This element includes clauses relating to the use made of each of the main base 

309 standards referenced in the profile definition. The content and layout of these 

310 clauses are not defined, but can be tailored to the type of material that has to be 

311 specified in each case. 

312 The information given shall not repeat the text of the base standards, but shall 

313 define the choices made in the profile of classes, subsets, options and ranges of 

314 parameter values. It shall be in the form of conformance requirements and may, 

315 where appropriate, be given in tabular form. 

316 See 6.3.3 for more detail concerning the nature of the content required in this ele- 

317 ment of a POSIX SP. 

318 A.8.4.2 Normative Annexes 

319 Normative annexes are integral sections of the POSIX SP that, for reasons of con- 

320 venience, are placed after all other normative elements. The fact that an annex is 

321 normative (as opposed to informative) shall be made clear by the way in which it 

322 is referred to in the text, by a statement to this effect in the foreword, and by an 

323 indication at the head of the annex itself. 

324 A.8.5 Supplementary Elements 

325 A.8.5.1 Informative Annexes 

326 Informative annexes give additional information and are placed after the norma- 

327 tive elements of a POSIX SP. They shall not contain requirements. The fact that 

328 an annex is informative (as opposed to normative) shall be made clear by the way 

329 in which it is referred to in the text, by a statement to this effect in the foreword, 

330 and by an indication at the head of the annex itself. 

331 Informative annexes provide a point for documenting useful information for the 

332 users of a profile that poses no requirements. Such annexes can include: 

333 (1) Specification of additional standards or options that will make the profile 

334 useful for specific locales (character sets, etc.) 

335 (2) Pointers to the referenced standards and information on ordering these 

336 (3) Pointers to related specifications that may provide additional insight or 

337 potentially serve to fill gaps in the profile 

338 (4) Comments and concepts in using the profile for various target readers. 

339 This could include use in procurements (perhaps cross referencing 
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340 related procurement standards like the FIPS in the US). The annex may 

341 be used to provide recommendations for use that are not warranted in 

342 the standard (e.g., “Algol is not recommended for new applications 

343 development”). 
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Annex B 

(informative) 

Bibliography 


1 Note to reviewers: This annex is not complete. It should include references to stan- E 

2 dards, hooks, articles, etc., that are not required for an integral understanding of E 

3 the document (as are the entries in Normative References). It currently consists E 

4 only of sample entries. It will be replaced in a later draft. E 


5 {Bl} ISO 7498: 1984, Information processing systems—Open Systems Inter- 

6 connection—Basic Reference Model . [) 


7 {B2} ISO 8072: 1986, Information processing systems—Open Systems Inter- 

8 connection—Transport service definition. 


9 {B3} ISO/IEC 8073: 1988, Information processing systems—Open Systems Inter¬ 
im connection—Connection oriented transport protocol specification . 2) 


11 

12 

13 

14 


{B4} CCITT Recommendation X.25, Interface between data terminal equipment 
(DTE) and data circuit-terminating equipment (DCT) for terminals operating 
in the packet mode and connected to public data networks by dedicated cir¬ 
cuit . 3) 


15 

16 
17 


{B5} CCITT Recommendation X.212, Information processing systems—Data 
communication—Data link service definition for Open Systems Interconnec¬ 
tion. 


18 {B5} ANSI X3.113-1987 4) , Information systems—Programming language—FULL 

19 BASIC. 


20 

21 

22 

23 

24 

25 

26 

27 

28 


1) ISO documents can be obtained from the ISO office, 1, rue de Varembe, Case Postale 56, CH-1211, 
Geneve 20, Switzerland/Suisse. 

2) IEC documents can be obtained from the IEC office, 3, rue de Varembe, Case Postale 131, CH- 
1211, Geneve 20, Switzerland/Suisse. 

3) CCITT documents can be obtained from the CCITT General Secretariat, International 
Telecommunications Union, Sales Section, Place des Nations, CH-1211, Geneve 20, 
Switzerland/Suisse. 

4) ANSI documents can be obtained from the Sales Department, American National Standards 
Institute, 1430 Broadway, New York, NY 10018. 
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29 {B6} IEEE Computer Society Technical Committee on Operating Systems and 

30 Application Environments Standards Subcommittee. TCOS-SSC POSIX 

31 Standards Style Guide. 

32 {B7} American Telephone and Telegraph Company. System V Interface 

33 Definition (SVID), Issues 2 and 3. Morristown, NJ: UNIX Press, 1986, 1989. 

34 {B8} /usr/group Standards Committee. 1984 /usr/group Standard. Santa 

35 Clara, CA: UniForum, 1984. 

36 {B9} X/Open Company, Ltd. X/Open Portability Guide, Issue 3. Englewood 

37 Cliffs, NJ: Prentice-Hall, 1989. 
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Annex C 

(informative) 

Standards Infrastructure Description 


i Responsibility: Wendy Rauch 


2 C.l Introduction 

3 This annex provides a brief summary of the major national and international 

4 organizations working on the standardization of information technology. 

5 There are two major categories of open standards organizations. One consists of 

6 formally-recognized standards bodies, responsible for definition and dissemina- 

7 tion of public standards. Their specifications are known as formal or de jure stan- 

8 dards. International, national, and regional standards groups, and some profes- 

9 sional and technical organizations’ standards groups are examples of formal stan- 

10 dards bodies. Organizations specifying standards for open system usually give 

n precedence to international standards first, then regional, national, and finally 

12 professional group standards. 

13 The other standards organization category consists of informal bodies. Informal 

14 standards bodies are typically created by suppliers or users of information tech- 

15 nology, usually using a consensus method, to enable the implementation of stan- 

16 dards. They produce specifications known as industry standards or de facto stan- 

17 dards. Certain trade associations, industry groups, vendor consortia, and user 

18 groups are examples of informal standards bodies. For informal specifications to 

19 be approved as formal standards (e.g., international or national standards) infor- 

20 mal standards groups typically submit their specifications to formal standards 

21 organizations. 

22 The term “de facto standard” is sometimes applied to popular vendor-defined sys- 

23 terns. Such systems, however, are closed systems, often controlled in a 

24 proprietary fashion. Although they have value, closed de facto standards are not 

25 the subject of this guide. 

26 Most standards bodies support three types of status for their standards or 

27 specifications—approved, draft, and work item. An approved standard is one that 

28 has been fully ratified by whatever means the approving standards body uses. A 

29 draft standard is one that has yet to be fully ratified, such as an ISO DIS (Draft 

30 International Standard) or a CEN ENV. Work item is a catch-all phrase for 
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31 everything else, such as immature specifications, technical reports, etc., that have 

32 not yet achieved draft status. 

33 C.1.1 International Standards Bodies Overview 

34 Standards with the highest status are internationally agreed ones. In informa- 

35 tion technology, these are produced and published by the International Organiza- 

36 tion for Standardization (ISO). Other standards and/or recommendations are 

37 issued by the International Electrotechnical Commission (IEC), the International 

38 Telecommunication Union (ITU), and the CCITT. International standards bodies 

39 participants are normally countries and trade bodies, rather than individual sup- 

40 pliers or users. 

41 C.1.2 National Standards Bodies Overview 

42 Like the international standards bodies, most national bodies do not admit either 

43 suppliers or users directly, but receive representatives from interested trade 

44 bodies. In general, the national bodies support and adopt the international stan- 

45 dards, developing national standards only if no international standards are avail- 

46 able, or to meet special national requirements. Each country has a national body 

47 that is the formal representative to the international standards groups. 

48 The relationship between the major international and national standards groups 

49 is shown in Figure C-l. 

50 C.1.3 International and National Standards Bodies Relationship 

51 Nongovernment standards organizations include trade associations, professional 

52 and technical societies, vendor consortia, user groups, and other special interest 

53 groups. Actual standards development occurs within these groups. The stan- 

54 dards specified by formal standards groups within this category typically are sub- 

55 sequently submitted to national or international standards organizations for 

56 approval. Many informal bodies submit their specifications to formal bodies for 

57 approval as an accredited standard. (See Figure C-l). 


58 C.2 The Formal Standards Groups 

59 C.2.1 International and National Standards Organizations 

60 NOTE: Only a few of the many national standards organizations are described in this subclause. 

61 However, the activities of these groups are representative of national standards groups in general. 
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62 


International 
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JTC 1 
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and 

Government 
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Specification 
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X3 


American 
National 
Standards 
Institute 
(ANSI) ^ 


Canadian 

National 

Standards 

Association 


IEEE NIST 


Asian 

National 

Standards 

Groups 


Australian 

National 

Standards 

Groups 


CEN/CENELEC 


European 

National 

Standards 

Groups 


EWOS 


/ \ 

Provide input into, and accelerate the development of, standards 
V___'_ ) 


Consortia 

(e.g., X/Open, OSF, Ul, 
X.400 APIA, SQL Access 
Group, NMF) 


Industry Associations 
(e.g., ECMA, EIA, ISA) 


Other Groups 
(e.g., COS, UniForum, 
MAP/TOP User Group. 
User Alliance) 


63 _ 

64 Figure C-l - Selected Major Standards and Standards-Influencing Bodies 


65 AFNOR: Association Francaise de Normalization 

66 AFNOR is the French national standards body. Its responsibilities include sourc- 

67 ing, coordinating, approving, and promoting standards, representing the French 

68 at international meetings, and controlling the use of the NF label—a trademark 

69 that shows compliance with a French national standard. AFNOR publishes three 

70 types of standards documents—AFNOR-approved standards that are mandatory 

71 for use in the public sector, experimental standards that use new processes or 

72 techniques and whose use is voluntary, and information or guide standards. 

73 For further information, contact Association Francaise de Normalization 

74 (AFNOR), Tour Europe - Cedex 7, 92080 Paris La Defense, Telephone: (1) 

75 42 91 55 55, Telex: AFNOR 611 974F, Fax: (1) 42 91 56 56. 
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76 ANSI: American National Standards Institute 

77 ANSI is the national standards coordinating and approval body for the United 

78 States. A voluntary organization founded in 1918, the ANSI performs three major 

79 types of functions. 

80 First, the ANSI approves standards and accredits standards development groups 

81 and certification programs. ANSI does not itself develop standards. Instead, it 

82 approves voluntarily-submitted specifications that were developed by technical 

83 and professional societies, trade associations, and special interest groups, if these 

84 specifications and/or groups meet ANSI criteria for due process and consensus. 

85 ANSI accredits three types of organizations. One is professional societies, such as 

86 the IEEE. The second is committees formed for the exclusive purpose of develop- 

87 ing standards, such as X3. The third is accredited by ANSI to use the canvass 

88 method to develop standards. Such organizations prepare a standard using their 

89 internal procedures. Then they submit that standard to balloting by other organi- 

90 zations representing a variety of interests. Last, they reconcile comments and 

91 objections returned. The NIST is an organization accredited to use the canvass 

92 process for standards development. 

93 ANSI’s second major function is to represent and coordinate US interests in inter- 

94 national, nontreaty, and nongovernmental standards bodies. ANSI’s third func- 

95 tion is to be a clearinghouse for national, international, and foreign national stan- 

96 dards. ANSI membership is open to manufacturers, organizations, users, and 

97 communications carriers. At present, more than 220 professional and technical 

98 societies and trade associations that develop standards in the US are ANSI 

99 members, as are 1000 companies. 

100 For further information, contact American National Standards Institute (ANSI), 

101 1430 Broadway, New York, NY 10018, (212) 354-3300, Telex: 42 42 96 ANSI UI. 

102 BSI: British Standards Institute 

103 BSI is the British national standards body and is responsible for promulgation of 

104 national standards. The BSI determines the overall UK view toward international 

105 standards and conveys that back to the secretariat of the international committee. 

106 For further information, contact British Standards Institute, 2 Park Street, Lon- 

107 don W1A2BS, United Kingdom, Telephone: 44 1 629 90 00, Fax: 44 1 629 05 06. 

108 Canadian Standards Association (CSA) 

109 The Canadian Standards Association (CSA), in conjunction with regulatory agen- 

no cies and with the provincial and national governments of Canada, provides a sin- 

111 gle source for consensus-based standards development, conformance testing, and 

112 standards-based regulations creation. The CSA has no single counterpart in the 

113 US. Instead, the CSA handles selected functions from US testing organizations, 

114 the FCC, and ANSI. 

115 Membership in the CSA is open to any Canadian citizen, business, or organiza- 

H6 tion. Members of the CSA’s technical committees developing standards are 
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117 volunteers, drawn from consumers, manufacturers, government, labor, and con¬ 
ns sultants. Membership is based on expertise in the field, and not, as in the US, 

119 mainly on having a vested commercial interest. The CSA has over 900 committees 

120 handling various aspects of standards in areas such as the environment, electrical 

121 and electronics, communications and information processing, construction, 

122 energy, transportation and distribution, materials technology, and production 

123 management. 

124 CSA programs support Canadian industry and Canadian consumers where safety 

125 and quality of merchandise sold or made in Canada are concerned. To assure pro- 

126 duct quality and safety, the CSA offers fee-based testing services. In performing 

127 such services, the CSA assumes that most manufacturers have the facilities to test 

128 their products before submitting them to the CSA for certification and approval. If 

129 they do not, the CSA provides this service. CSA certification involves the submis- 

130 sion of the product or service by the supplier, the verification of that product or 

131 capability by the CSA, and then continued follow-up audits by the CSA to ensure 

132 that the quality of the product or service is maintained. 

133 For further information, contact (Address and phone number TBD). 

134 CCITT: Comite Consultatif International de Telegraphie et Telephonie 

135 An international organization, the CCITT is part of the International Telecom- 

136 munications Union, which is a United Nations treaty organization formed in 

137 1865. It is now a specialized agency of the United Nations. 

138 The CCITT’s primary mission is to develop standards supporting the international 

139 interconnection and interoperability of telecommunications networks at interfaces 

140 with end-user systems, carriers, information and enhanced-service providers, and 

141 customer premises equipment. Every four years, the CCITT publishes the results 

142 of its work as “Recommendations.” Its recommendations are law where communi- 

143 cations in Europe are nationalized. 

144 Membership and participation in the CCITT are open to private companies; 

145 scientific and trade associations; and postal, telephone, and telegraph administra- 

146 tions. CCITT’s principal participants are telecommunications administrations and 

147 carriers. Scientific and industrial organizations can participate as observers. The 

148 US representative is the Department of State. 

149 For further information, contact International Consultative Committee on Teleg- 

150 raphy and Telephone, Central Administration Office, CH-1211, 2 rue de Varembe, 

151 Geneva, Switzerland, 

152 CEN/CENELEC/CEPT 

153 The Comite Europeen de Normalisation (CEN), Comite Europeen de Normalisa- 

154 tion Electrotechnique (CENELEC), and the European Committee for Post and 

155 Telecommunications Administration are European regional standards committees 

156 responsible for developing and publishing European standards. CEN is an associ- 

157 ation of EC (European Community) and EFTA (European Free Trade Association) 

158 members. It is active in making members’ standards into ISO standards and 
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159 European standards. CENELEC is the counterpart of CEN that deals exclusively 

160 with electrotechnical matters. CEPT is the CEN counterpart that deals with 

161 telecommunications matters. 

162 CEN, CENELEC, and CEPT can be considered the European regional equivalent of 

163 ISO for two reasons. First, they have as members the national standards bodies 

164 of their eighteen EC and EFTA member states. Second, standards adopted by 

165 these organizations must be implemented in full as national standards, regard- 

166 less of the way in which the member voted, and regardless of any standards that 

167 conflict with them must be withdrawn. CEN members, for example, agree to use 

168 its published standards in preference to national standards, wherever possible. 

169 CEN, CENELEC, and CEPT were created to improve the competitiveness of Euro- 

170 pean enterprise by removing technical barriers to trade and facilitating the free 

171 movement of goods within Europe. To accomplish its aims, CEN, CENELEC, and 

172 CEPT perform the following tasks: 

173 — Create and promote European Standards (EN). 

174 — Rapidly create prestandards (ENV) in technology areas in which there is a 

175 high level of innovation or where it is felt that future standardization 

176 requires basic guidance. ENVs are subjected to an experimental period of 

177 up to three years. 

178 — Create harmonization documents (HD) that are more flexible than Euro- 

179 pean Standards so that the technical, historical, or legal circumstances per- 

180 taining to each country can be taken into account. 

181 — Set up a framework for European certification that supports the issuing of 

182 a European mark of conformity to certain standards and the mutual recog- 

183 nition of test results and inspections. 

184 — Promote the application within Europe of ISO standards and accelerate 

185 their production. 

186 — Work in liaison with European professional federations and numerous 

187 technical organizations to establish priority standards programs and contri- 

188 bute to the technical work. 

189 For further information, contact the European Committee for Standardization 

190 (CEN), European Committee for Post and Telecommunications Administration, 2 

191 rue Brederode, Suite 5, B-1000 Brussels, Belgium, Telephone: +322 519 6860, 

192 Telex: 26257 CENLEC. 

193 DIN: Deutsches Institut fur Normung 

194 DIN is the German national standards body. Its functions include those per- 

195 formed by the US’s ANSI (e.g., developing national standards and representing 

196 Germany in international and European standards bodies such as ISO, the IEC, 

197 CEN, and CENELEC), in addition to test and certification functions that are not 

198 handled by US consensus standards organizations. Since a key DIN objective is 

199 eliminating technical barriers to free trade, DIN plays an active role in the inter- 

200 national standards arena to ensure that German products can be used and 
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201 accepted internationally. 

202 DIN standards are not mandatory within Germany. DIN claims that it relies on 

203 the technical excellence of its standards to win converts. Further incentive for 

204 accepting DIN standards is provided because DIN standards serve as the basis for 

205 regulatory technical law in Germany. Also, without the DIN testing and inspec- 

206 tion mark, no insurance carrier in Germany will write insurance for a product. 

207 DIN members include groups within Germany representing manufacturers, the 

208 academic community, user groups, user organizations (e.g., consumer advocate 

209 groups), the government, and trade unions. Many DIN staff are supported by 

210 organizations or companies, rather than by DIN. DIN presently has over 20 000 

2 11 standards. 

212 For further information, contact Deutsches Institut fur Normung, Burggrafen- 

213 strasse 6, Postfach 1107, D-1000 Berlin 30, Telephone: 49 30 26 01-1, Fax: 

214 49 30 260 12 31. 

215 IEC: International Electrotechnical Commission 

216 The International Electrotechnical Committee is the equivalent of ISO, but for 

217 electrotechnical standards. ISO and the IEC have converged many of their infor- 

218 mation technology efforts to form JTC 1. 

219 For further information, contact International Electrotechnical Commission (IEC), 

220 3, rue de Varembe, CH-1211 Geneva 20, Switzerland, Telephone: 41 22 34 01 50, 

221 Fax: 41 22 33 38 43. 

222 ISO: International Organization for Standardization 

223 ISO was established in its present form in 1947 with the aim of reaching interna- 

224 tional agreement on standards. A voluntary, non-United Nations treaty, ISO’s 

225 membership consists of delegations from standards bodies in participating 

226 nations. ISO solicits comments from other groups as well, including ECMA, the 

227 IEEE, the NIST, and the CCITT. ISO has a close relationship with the CCITT, 

228 which is, perhaps, the most influential of all the observer groups within ISO. 

229 ISO is responsible for the development and standardization of the Open Systems 

230 Interconnection (OSI) model. It also considers items for standardization that were 

231 developed in other standards bodies, such as ANSI. At present, for example, it is 

232 considering the core POSIX standard (P1003.1). 

233 For further information, contact the International Organization for Standardiza- 

234 tion, Central Secretariat, 1, rue de Varembe, CH-1211, Geneva, Switzerland-40. 

235 JISC: Japanese Industrial Standards Committee 

236 The Japanese Industrial Standards Committee (JISC) is the national standards 

237 body of Japan. The JISC represents Japan at ISO and IEC, develops Japanese 

238 standards, and monitors and liaises with the standards-developing activities of 

239 other national organizations, especially those of the US. The goal of the JISC is to 

240 ensure that Japanese industry can compete internationally in the information 
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241 technology and telecommunications industries. 

242 The JISC has no true counterpart in other nations since the JISC has a special 

243 relationship with the Japanese government and major manufacturers. For exam- 

244 pie, the JISC’s secretariat is the Agency of Industrial Science and Technology, a 

245 division of the Ministry of International Trade and Industry (MITI), which plays a 

246 central role in Japanese industry. The influence of this centralized national plan- 

247 ning structure eliminates many areas of contention, including among companies 

248 with multinational branches, and facilitates the ability for Japanese standards 

249 groups to gain a consensus. 

250 Major Japanese manufacturers help plan and develop standards. Foreign com- 

251 panies’ involvement in the JISC is limited because of geographic and linguistic 

252 differences and because of restrictions on their meaningful participation. 

253 Although large-scale manufacturers may participate, user groups and small 

254 manufacturers find participation very difficult. 

255 For information, contact Japanese Industrial Standards Committee, c/o Stan- 

256 dards Department, Agency of Industrial Science and Technology, Ministry of 

257 International Trade and Industry, 1-3-1 Kasumigaseki, Chiyoda-ku, Telephone: 

258 813 501 92 95/6, Fax: 81 3 580 14 18. 

259 JTC 1: Joint Technical Committee 1 

260 The JTC 1, established in 1987, is the first joint committee of the ISO TC97 (Infor- 

26 1 mation Processing Systems) and its subcommittees, with the IEC Technical Com- 

262 mittee 83 (Information Technology Equipment) and the subcommittee IEC SC47B 

263 (Microprocessor systems). The joint committee was formed to eliminate much of 

264 the two groups’ standardization-activities’ overlap and prevent the creation of 

265 incompatible standards for the same device or technology area. 

266 Although ISO and IEC are equal partners in the management of JTC 1, most of 

267 JTC l’s standards work grew out of ISO’s information processing work. In fact, 

268 JTC 1 has become one of the most important information technology standards 

269 organizations today because so many of the major ISO information technology 

270 standards being developed today are actually being produced by JTC 1 groups. 

271 The JTC l’s purpose is to develop international standards in the areas of informa- 

272 tion technology systems (including microprocessor systems) and equipment. 

273 Microprocessor systems include, but are not limited to, microprocessor assem- 

274 blies, and related hardware and software for controlling the flow of signals at the 

275 terminals of microprocessor assemblies. 

276 The JTC 1 initially organized its standards work into four major groupings, each 

277 of which contains subcommittees that, in turn contain working groups. The four 

278 main groupings and their subcommittees are: 

279 JTC 1 Application Elements Group 

280 SCI: Vocabulary 

281 SC7: Software Engineering 
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282 SC14: Representation of Data Elements 

283 SC22: Languages 

284 JTC 1 Equipment and Media Group 

285 SC11: Flexible Magnetic Media for Digital Data Interchange 

286 SC 15: Labeling and File Structure 

287 SC17: Identification and Credit Cards 

288 SC23: Optical Disk Cartridges for Information Interchange 

289 SC28: Office Equipment 

290 JTC 1 Systems Group 

291 SC6: Telecommunications and Information Exchange Between Sys- 

292 terns 

293 SC 13: Interconnection of Equipment 

294 SC18: Text and Office Systems 

295 SC21: Information Retrieval, Transfer, and Management for OSI 

296 JTC 1 Systems Support Group 

297 SC2: Character Sets and Information Coding 

298 SC24: Computer Graphics 

299 SC25: Interconnection of Information Technology Equipment (form- 

300 erly IEC TC83) 

301 SC26: Microprocessor Systems (formerly IEC TC47B) 

302 SC27: Security Techniques (grew out of JTC 1 SC20: Data Crypto- 

303 graphic Techniques) 

304 POSIX standardization work is being done within SC22’s Working Group 15 

305 (SC22/WG15). A JTC 1 Special Working Group on Strategic Planning is perform- 

306 ing a technical study on Application Portability (AP). This study’s goal is to iden- 

307 tify the standards that need to be written or revised to support application porta- 

308 bility between hardware and software environments. 

309 The JTC 1 is not involved in application-specific information technology areas, 

310 such as banking and industrial automation systems, nor is it concerned with 

3 11 microprocessor subsystems covered by the scopes of IEC TC22 on power electronics 

312 or TC86 on fiber optics. 

313 The JTC 1 has liaison relationships with numerous ISO and IEC Technical Com- 

314 mittees, as well as with the CCITT. 

315 Like ISO, membership in JTC 1 consists of delegations from standards organiza- 

316 tions in member countries. At present, 23 countries participate in JTC 1, and 

317 there are another 11 observer countries. The ANSI holds the secretariat for JTC 1. 
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318 For further information, contact: American National Standards Institute (ANSI), 

319 1430 Broadway, New York, NY 10018, (212) 354-3300, Telex: 42 42 96 ANSI UI, or 

320 International Organization for Standardization (ISO), Central Secretariat, 1, rue 

321 de Varembe, CH-1211, Geneva, Switzerland-40. 

322 SGFS (Special Group on Functional Standardization) 

323 The Special Group on Functional Standardization (SGFS) is an ISO group, under 

324 JTC1, which is responsible for the international standardization process of 

325 profiles or functional standards. 

326 C.2.2 Nongovernment Formal Standards Organizations 

327 ECMA: European Computer Manufacturers Association 

328 Established in 1961 to develop data processing standards, ECMA is a trade organ- 

329 ization, open to any computer firm developing, manufacturing, or selling in 

330 Europe. The ECMA has about 20 members, and approximately 13 active Techni- 

331 cal Committees. 

332 ECMA contributes to the ISO standards development efforts, in addition to issuing 

333 its own standards. ECMA is particularly active in the development of higher layer 

334 protocols for OSI networking. It also is developing a standard for a Portable Com- 

335 mon Tool Environment (PCTE). 

336 For further information, contact European Computer Manufacturers Association, 

337 114 rue du Rhone, CH-1204 Geneva, Switzerland, Telephone: 41-22-735-36-34, 

338 Telex: 41 3237, Fax: 41 22 786 53 31. 

339 EIA: Electronic Industries Association 

340 The EIA is a US trade organization, whose membership consists primarily of 

341 manufacturers. The EIA has been a standards developer in the areas of electrical 

342 and electronic products and components since 1926. Many of its standards have 

343 been submitted to ANSI and approved as ANSI standards. The EIA is best known 

344 for the RS-232-C standard. 

345 For further information, contact John Kinn, Vice President - Engineering, Elec- 

346 tronic Industries Association (EIA), 2001 I Street NW, Washington, DC 20036, 

347 (202) 467-4961. 

348 IEEE: Institute of Electrical and Electronic Engineers 

349 The IEEE is a professional scientific, engineering, and educational society that 

350 develops and publishes standards and specifications in a variety of computer and 

351 engineering areas. The standards and specifications published are of three types: 

352 true standards, recommended practices, and guides. 

353 “Standards” are specifications with mandatory requirements. Recommended 

354 practices are specifications of procedures and positions preferred by the IEEE. 

355 Guides are specifications that suggest alternative approaches to good practice, but 
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356 make no clear-cut recommendations. The IEEE is accredited by ANSI, and can, 

357 therefore, submit its standards directly to the ANSI board of Standards Review. 

358 All new and revised IEEE standards are submitted to ANSI for review and adop- 

359 tion as ANSI standards. 

360 The IEEE Standards Board authorizes, coordinates, and approves all standards 

361 projects, and coordinates cooperation with other standards organizations. Stan- 

362 dards are proposed and sponsored by technical committees of the IEEE Societies, 

363 standards committees, or Standards Coordinating Committees (SCC), depending 

364 on the scope of the work. Either these committees or standards subcommittees 

365 manage the actual standards development and balloting. The individual draft 

366 standards are specified in working groups inside the subcommittees—one working 

367 group per standard (see Figure C-2). 

368 IEEE membership is open to any dues-paying individuals. Standards participants 

369 are individuals, not companies or organizations. IEEE membership is required for 

370 voting, but not for participating in the development of draft standards. 

371 Approximately 30000 members are active in standards development. More than 

372 5 00 IEEE standards exist, and more than 800 standards projects are underway. 

373 The IEEE also administers the secretariat or cosecretariat of 17 American 

374 National Standards committees. 

375 The most well known IEEE standards are the IEEE 802.3 CSMA/CD and 802.4 

376 token bus LANS, IEEE-488 bus, the National Electrical Safety Code, and the 

377 P1003.n POSIX standards. The 802.3 and 802.4 standards are also approved ISO 

378 standards. The core POSIX standard (POSIX. 1 {2}) has been approved by ISO, and 

379 is now an ISO, as well as an IEEE, standard. The POSIX.O specifications, with 

380 which this document is concerned, will be, in IEEE parlance, a “Guide” to a POSIX 

381 Open System Environment. 

382 For further information, contact the Institute of Electrical and Electronics 

383 Engineers, Inc., 345 East 47th Street, New York, NY 10017, USA. 

384 NIST: National Institute of Standards and Technology 

385 The National Institute of Standards and Technology (formerly the National 

386 Bureau of Standards) was established by an act of the US Congress on March 3, 

387 1901 to advance, and facilitate the application of, US science and technology for 

388 public benefit. Toward this end, the Institute for Computer Sciences and Technol- 

389 ogy (ICST) within the NIST, conducts research and provides technical advisory ser- 

390 vices to help Federal agencies acquire and apply computer technology. 

391 The NIST is a major driving force behind standards development. Through the 

392 Institute for Computer Sciences and Technology, the NIST develops and publishes 

393 Federal Information Processing Standards (FIPS) for the United States. Federal 

394 agencies to use in their computer equipment procurements. Federal agencies are 

395 obligated to use these standards, where applicable. 

396 Federal computer standards also are widely used by the private sector, and often 

397 are adopted as ANSI standards. Besides defining standards, the NIST has defined 

398 an Application Portability Profile (APP), which comprises a series of 
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402 nonmandatory specifications and a guide for US government users to use in 

403 developing a portable, interoperable architecture and environment. 

404 The development and evolution of both FIPS and the APP is carried out in conjunc- 

405 tion with users and vendors through an ongoing series of NIST-conducted Imple- 

406 mentor Workshops and User Workshops (e.g., OSI implementors workshops, APP 

407 workshops, and Integrated Software Engineering Environment workshops). The 

408 workshops provide forums for user and vendor feedback and comments on evolv- 

409 ing NIST standards, and help ensure that there is a general commitment among 

4 10 vendors to building products that conform to the evolving NIST specifications. 

4 11 Additionally, the NIST develops test methods and performance measures to help 

412 users and vendors implement standards and to test the conformance of vendor 
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413 implementations to FIPS specifications. Among others, the NIST has test suites 

414 for most FIPS programming languages, FIPS Database SQL, and POSIX.1 {2}. The 

415 POSIX.1 {2} conformance test suite, however, is based on the conformance-test 

416 assertions developed in the POSIX Test and Methods working group (P1003.3.1). 

417 Besides developing its own standards, NIST staff members participate in a 

418 number of other standards activities and organizations, including the ANSI X3 

419 Committee on Information Processing Systems, ISO/IEC JTC 1, CCITT, ECMA, and 

420 the IEEE. 

421 For further information, contact the National Institute of Standards and Technol- 

422 ogy, Gaithersburg, MD 20899, Telephone: (301) 975-2000. E 

423 T1 

424 Tl, established in 1984, is an ANSI-accredited standards body that is developing 

425 standards and technical reports. The standards and reports are intended to sup- 

426 port interconnection and interoperability of telecommunications networks at 

427 interfaces with end-user systems, carriers, information and enhanced-service pro- 

428 viders, and customer premises equipment. 

429 Six Tl technical subcommittees are currently developing these standards and 

430 reports under the Tl Advisory Group. The subcommittees also recommend posi- 

431 tions on matters under consideration by other North American and international 

432 standards bodies. 

433 Tl Membership and full participation is available to all interested parties. For 

434 further information, contact Alvin Lai, Exchange Carriers Standards Association, 

435 c/o Tl Secretariat, 5430 Grosvenor Lane, Suite 200, Bethesda, Maryland 

436 20814-2122, or call (301) 654-4505. 

437 X3 

438 X3, established in 1961, is an ANSI-accredited standards body that develops corn- 

439 puter, information processing, and office systems standards. X3 also participates 

440 in the development of international standards in these areas. In addition, it 

441 serves as a Technical Advisory Group (TAG) to ANSI for most of the subcommit- 

442 tees working on international standardization projects within JTC 1. The Com- 

443 puter and Business Equipment Manufacturers Association (CBEMA) functions as 

444 X3’s secretariat. 

445 X3 membership is open to all organizations, upon payment of a service fee. The 

446 current membership includes computer manufacturers, communications carriers, 

447 user groups, and government agencies. More than 3200 volunteers from these 

448 organizations participate in the X3 standards work. They are organized into 

449 about 85 technical groups, working on 700 projects. 

450 Three standing committees report to X3: the Standards Planning and Require- 

451 ments Committee (SPARC), the Strategic Planning Committee (SPC), and the 

452 Secretariat Management Committee (SMC). The following are the major X3 

453 technical committees: 
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454 

Recognition 


455 

X3A1 

Optical Character Recognition 

456 

Media 


457 

X3B5 

Digital Magnetic Tape 

458 

X3B6 

Instrumentation Tape 

459 

X3B7 

Magnetic Disks 

460 

X3B8 

Flexible Disk Cartridges 

461 

X3B9 

Paper/Forms Layout 

462 

X3B10 

Credit/Identification Cards 

463 

X3B11 

Optical Digital Data Disks 

464 

Data Management and Graphics 

465 

X3H2 

Database 

466 

X3H3 

Computer Graphics 

467 

X3H3.6 

Windowing Interfaces 

468 

X3H4 

Information Resource & Dictionary 

469 

Languages 


470 

X3J1 

PL/1 

471 

X3J2 

Basic 

472 

X3J3 

Fortran 

473 

X3J4 

COBOL 

474 

X3J7 

APT 

475 

X3J9 

Pascal 

476 

X3J10 

APL 

477 

X3J11 

C 

478 

X3J12 

Dibol 

479 

X3J13 

Common Lisp 

480 

X3J14 

Forth 

481 

X3J15 

Databus 

482 

Documentation 


483 

X3K1 

Computer Documentation 

484 

X3K5 

Vocabulary 

485 

Data Representation 
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486 

X3L2 

Codes and Character Sets 

487 

X3L5 

Labels and file Structure 

488 

X3L8 

Data Representation 

489 

C ommunication 

490 

X3S3 

Data Communications 

491 

Systems Technology 

492 

X3T1 

Data Encryption 

493 

X3T2 

Data Interchange 

494 

X3T5 

Open Systems Interconnection 

495 

X3T9 

I/O Interface 

496 

Text 


497 

X3V1 

Office and Publishing Systems 


498 For more information, contact CBEMA, c/o X3 Secretariat, 311 First Street NW, 

499 Suite 500, Washington, DC 20001-2178, Telephone: (212) 626-5740. 


500 C.3 Related Organizations e 

501 The following organizations are some of the major trade associations, user groups, 

502 and professional bodies active in either promoting, implementing, or reviewing 

503 information technology standards. 

504 E 

505 CBEMA: Computer and Business Equipment Manufacturers Association 

506 CBEMA is a trade organization whose primary function is to represent large 

507 manufacturers of hardware-based information technologies equipment in lobbying 

508 about public policy. In addition, it provides education programs, information 

509 exchange forums, and deals with the industry’s public image. 

510 CBEMA has long had an interest in standards. It serves as the secretariat for X3. 

511 It also offers a standards and technology program where its members can 

512 exchange information on standards issues and industry standards. 

513 CBEMA’s members are mostly large manufacturers because its dues are tied to 

514 corporate revenues and structured in a way that makes it too expensive for small 

515 companies to join. Members are either American companies or US subsidiaries of 

516 non-American companies. 

517 For more information, contact CBEMA, 311 First Street, NW, Suite 500, Washing- 

518 ton, DC 20001-2178, Telephone: (202) 626-5740. 
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519 CODASYL: The Conference on Data Systems Languages 

520 The Conference on Data Systems Language (CODASYL) has been active since 

521 1960 in the development of the COBOL language, through its COBOL Committee 

522 (CC). Since 1969, it also has been active in the development of a common Data 

523 Description Language for defining schemas and subschemas, and in a data mani- 

524 pulation language, through the DBTG Data Base Task Group of the CC. The 

525 activities of the CC are documented in the COBOL Journal of Development, which 

526 serves as the official COBOL language specification. 

527 In 1969, ANSI (then the United States of America Standards Institute) issued the 

528 first COBOL standard. At that time, the X3.4 committee stated that X3.4 recog- 

529 nizes the CODASYL COBOL Committee as the development and maintenance 

530 authority for COBOL. In practice, this meant that ANSI agreed not to make any 

531 changes to the CODASYL-defined language specification. Although this agreement 

532 has been challenged over the years, the CODASYL-ANSI agreement is still strong. 

533 As a result, the CODASYL has enormous influence upon the COBOL language. 

534 Toward the end of 1971, a new CODASYL committee was established—the Data 

535 Description Language Committee (DDLC). The DDLC was formed to serve the 

536 same functions for the schema DDL as the CC does for COBOL. That is, since the 

537 schema DDL is a conceptual schema and network-model database language for 

538 use with many programming languages, not just COBOL, the DDLC continues the 

539 schema DDL development and publishes its own Journal of Development docu- 

540 menting the language’s current status. 

541 The COBOL DML and subschema DDL (for defining an external view) of the DBTG 

542 are COBOL-specific and have remained part of the CC under the name “The 

543 COBOL Data Base Facility.” 

544 The CODASYL membership is composed of voluntary representatives, mostly from 

545 computer manufacturers and users in industry and the US Federal government. 

546 COS: Corporation for Open Systems 

547 COS is a US-based, international, nonprofit association of vendors and users, 

548 formed in 1985 to promote and accelerate the adoption of interoperable, multiven- 

549 dor products and services based on OSI and ISDN standards. To accomplish its 

550 goals, COS provides a user-vendor forum for the statement of user requirements 

551 and the discussion and management of the issues surrounding the deployment of 

552 open systems. COS also identifies test requirements, and sponsors test tools 

553 development and conformance and interoperability testing to verify that computer 

554 products and services conform to OSI or ISDN standards. 

555 COS’s membership consists of more than 60 prominent manufacturer, user, and 

556 telecommunication service organizations worldwide. COS cooperates with similar 

557 organizations such as SPAG Services in Europe and POSI in Japan. Other key 

558 groups in the worldwide promotion, implementation and testing of OSI and ISDN 

559 standards are affiliated with COS under its Alliance Associate program. 

560 For further information, contact the Corporation for Open Systems, 1750 Old 

561 Meadow Road, Suite 400, McLean, VA 22102-4306, USA, Telephone: 
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562 (703) 883-2700, Fax: (703) 848-8933. In Europe contact Corporation for Open 

563 Systems, Avenue des Arts 1-2, bte 11, 1040 Bruxelles, Belgique, Telephone: 

564 32 2 210 08 11, Fax: 32 2 210 08 00. 

565 E 

566 EPRI: Electric Power Research Institute 

567 The Electric Power Research Institute’s (EPRI) is an industry association con- 

568 cerned with electric power utilities. Its membership comprises more than 673 

569 publicly and privately owned utilities in the United States. Besides providing a 

570 variety of utility-specific services to its membership, EPRI’s latest mission is to 

571 facilitate the use of open systems technology in the utility industry. 

572 Toward this end, EPRI has developed a Utilities Communication Architecture 

573 (UCA), which is similar to the National Institute for Standards and Technology’s 

574 (NIST) Government Open Systems Interconnect Profile (GOSIP) Version 2.0. 

575 Much of the UCA was developed by EPRI with the cooperation of Honeywell and 

576 Anderson Consulting. 

577 EPRI’s specific open system interests span realtime UNIX, expert systems, and 

578 database access using RDA and SQL. Because of the financial structure of the util- 

579 ities industry, EPRI wants to encourage these and other open systems technolo- 

580 gies for equipment with a 12 to 15 year life cycle. 

581 For further information, contact EPRI’s headquarters at 3412 Hillview Avenue, 

582 P.O. Box 10412, Palo Alto, CA 94303, Telephone: (415)934-4212. 

583 ESPRIT (European Strategic Programme for Research and Development 

584 in Information Technology) 

585 The European Strategic Programme for Research and development in Information 

586 Technology is a European research programme initiative, started in 1982 and 

587 sponsored by the Commission of the European Communities. About 227 projects 

588 were implemented during the first phase of the project in five major work areas: 

589 advanced microelectronics, software engineering and technology, advanced infor- 

590 mation processing, office automation, and computer integrated manufacturing. 

591 Nearly thirty projects have enabled substantial advances to be made in establish- 

592 ing internationally recognized standards. Examples of the Portable Communica- 

593 tions Tool Environment (PCTE) project, the Communication Network for Manufac- 

594 turing Applications (CNMA) project, and the Herode project, which has prepared 

595 an Office Document Architecture standard for adoption as an ISO standard. 

596 The second phase of the Esprit programme will be concerned mainly with three 

597 areas—microelectronics and peripheral technologies; the creation of technologies 

598 and tools for the design of information processing systems; and enhancing the 

599 capacity for using and integrating information technology to extend the scope of 

600 its applications. 

601 For further information contact ESPRIT, Director General, DG XIII, CEC, rue de la 

602 Loi 200, B-1049 Brussels, Belgium, Telephone: (32 2) 235 11 11, and Telex: 
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603 21877 comeu b. 

604 ETSI: European Telecommunications Standards Institute 

605 The European Telecommunications Standards Institute (ETSI), founded in 1988, 

606 is a voluntary standards organization involved in producing the telecommunica- 

607 tions standards necessary to achieve a European unified market. ETSI was esta- 

608 blished outside the CEN/CENELEC framework. ETSI, however, works with CEN, 

609 CENELEC, and the European Broadcasting Union (EBU) in areas of mutual 

610 interest. 

611 ETSI’s voting membership consists of postal administrations, along with manufac- 

612 turers and trade associations, in each of the CEPT countries. Membership is not 

613 restricted to official representatives of member countries. The United States and 

614 US companies have been granted observer status. 

615 Standards approved by ETSI are voluntary standards known as ETS (European 

616 Telecommunications Standards). ETSI also conducts prestandardization studies, 

617 develops technical reports and guidelines, holds conferences, workshops, sem- 

618 inars, and conducts interviews. ETSI’s interim standards are designated I-ETS. 

619 For further information, contact the European Telecommunications Standards 

620 Institute, B.P. No. 52, F-06561 Valbonne CEDEX, France, Telephone: 

62 1 (33 92) 94 42 00, Telex: 470 040 F, and Fax Number: (33 93) 65 47 16. 

622 EWOS: European Workshop for Open Systems 

623 The EWOS is an ongoing regional workshop, formed in 1987, to provide and coor- 

624 dinate European input to the international standard profiles process. It was 

625 formed as the result of an initiative of SPAG, in conjunction with CEN/CENELEC. E 

626 EWOS is the focal point in Europe for the study and development of OSI profiles 

627 and corresponding conformance test specifications. EWOS documents have only to 

628 be submitted to public enquiry by CEN and CENELEC before becoming European E 

629 norms. E 

630 For further information contact European Workshop on Open Systems (EWOS), 

631 rue de Brederode 13, B-1000 Brussels, Belgium, Telephone: 32 2 511 74 55. 

632 E 

633 INTAP (Interoperability Technology Association for Information Process- 

634 ing) 

635 The Interoperability Technology Association for Information Processing, in Japan, 

636 is a national agency, funded by MITI. It deals with information technology, and 

637 specifically OSI products and advanced projects. INTAP is developing and provid- 

638 ing conformance testing tools and services in Japan in cooperation with POSI. 
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639 MAP/TOP User Group: (Manufacturing Automation Protocol and Techni- 

640 cal and Office Protocol) 

641 The MAP Task Force was formed in 1980 by engineers from seven General Motors 

642 (GM) divisions, to identify a common OSI-based networking standard for plant- 

643 floor systems. The Task Force grew to include all GM divisions, many other users, 

644 and many vendors. Its specifications are known as Manufacturing Automation 

645 Protocol (MAP). 

646 The MAP specifications mostly reference OSI standards, but they also draw on 

647 ANSI, IEEE, EIA, CCITT, and various industry standards. Where standards do not 

648 exist, as in the case of the manufacturing messaging protocol, the MAP Task Force 

649 is either defining its own or instigating their formation by industry standards 

650 bodies. 

651 In 1984, the MAP Users Group was formed, under the auspices of GM, with the 

652 Society of Manufacturing Engineers as its Secretariat. Its objective is to promote 

653 knowledge and use of MAP, and to insure input from users. 

654 In 1985, Boeing sponsored a similar effort to specify common networking proto- 

655 cols, known as the Technical and Office Protocols (TOP), for the engineering and 

656 business offices. TOP is largely compatible with MAP, differing only at the lower 

657 two layers and the application layer where TOP addresses requirements of the 

658 technical and office user, rather than factory users. 

659 Later in 1985, a TOP Users Group was formed. The entire effort became an inter- 

660 national effort known as MAP/TOP, and the user group became the MAP/TOP User 

66 1 Group, which meets twice a year. 

662 Today, the MAP/TOP User Group is an independent, self-funded organization that 

663 represents thousands of users worldwide, tied together through a worldwide 

664 federation of MAP/TOP user groups. Membership is open to either users or corn- 

665 panies. The Industry Cooperative Services (ICS) is the worldwide secretariat. 

666 The MAP/TOP User Group also is a member of the Corporation for Open Systems 

667 (COS) and in North America, COS acts as the MAP/TOP User Group secretariat. 

668 The MAP/TOP User Group is a Requirements Interest Group (RIG) of the Corpora- 

669 tion for Open Systems (COS). This means that the MAP/TOP User Group gen- 

670 erates requirements that vendors can use to built products. COS serves as the 

671 coordinator between users and vendors. 

672 The MAP/TOP Task Force and User Group also is a major contributor of technical 

673 and conceptual ideas and specifications to the NIST, COS, and many of the IEEE 

674 POSIX Groups. 

675 For further information contact the World Federation of MAP/TOP Users Groups, 

676 P.O. Box 1457, Ann Arbor, MI 48106, Telephone: (313) 769-4571, Fax: 

677 (313) 769-4064. In North America, also contact the Corporation for Open Systems 

678 at 1750 Old Meadow Road, Suite 400, McLean, VA 22102-4306, Telephone: 

679 (703) 883-2700, Fax: (703)848-8933. 

680 E 
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681 Network Management Forum 

682 A vendor-driven group, the Network Management Forum is chartered to produce 

683 a commonly agreed-upon specification subset of ISO’s network management proto- 

684 cols and the command sets to implement this subset. The promise of the NMF is 

685 that all of the network management products that its members come up with will 

686 conform to this common specification. 

687 The NMF itself will produce no products nor will it specify implementations. 

688 Rather, the NMF will specify interfaces. 

689 Major vendors belong to the NMF from both the computer and telecommunications E 

690 industries. The NMF has published Release 1 of its specifications (1990). Member E 

691 firms are developing products that conform to Release 1. 

692 NMF information may be had from the organization at 40 Morristown Road, Ber- 

693 nardsville, NJ 07924. Telephone: (201) 766-1544. 

694 NPSC: National Protocol Support Center 

695 An Australian organization, the National Protocol Support Center was formed in 

696 1986 as a joint effort between industry and the government. Like SPAG, COS, and 

697 POSI, the NPSC is promoting the adoption of OSI standards in information tech- 

698 nology products and will be supporting a conformance testing capability in Aus- 

699 tralia. The Australian government, however, provides approximately 50 percent 

700 of the NPSC funding. For further information, contact (contact address and other 

701 information TBD). 

702 Object Management Group 

703 Founded in 1989 and headquartered in Framingham, MA, with marketing opera- 

704 tions in Boulder, CO, the Object Management Group (OMG) is an international 

705 organization of more than 146 systems vendors, software developers and users. 

706 The OMG was founded to promote the theory and practice of object management 

707 technology in the development of software. 

708 The OMG’s goal is to develop a common framework, based on industry-derived 

709 guidelines, that is suitable for object-oriented applications. The adoption of this 

710 framework will make it possible to develop a heterogeneous applications environ- 

711 ment across all major hardware and operating systems. 

712 The OMG members are quick to form a consensus on certain object management 

713 issues because they see these issues directly affecting their software sales. For 

714 example, the OMG’s object request broker design—key software needed to allow 

715 disparate open systems to request object services from remote sites—is supported 

716 by most major object-oriented software vendors. E 

717 Further information is available from the OMG at 492 Old Connecticut Path, 

718 Framingham, MA 01701. Telephone: (508) 820-4300. 
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719 OSF: Open Software Foundation 

720 The Open Software Foundation is a nonprofit, international consortium. Its goals E 

721 include the development of software specifications and test suites for an open E 

722 computing environment. E 

723 OSF specifications are defined, and software developed, using an open process into 

724 which vendors and users have input and access. The resulting AES specifications E 

725 will be available in the public domain, and the software licensable, to OSF E 

726 members and nonmembers, under identical terms. Both members and non- E 

727 members can also submit technologies to the OSF for consideration as an OSF E 

728 specification and/or offering. OSF’s specifications and software will be based on E 

729 the ISO/IEC 9945-1 core POSIX standard (POSIX.1 {2}), a variety of international, E 

730 national, and industry standards and other consortia specifications. The E 

731 remainder of OSF software and specifications will be based on technologies contri- E 

732 buted by numerous companies and universities as part of OSF’s Request for Tech- E 

733 nology (RFT) process. E 

734 OSF active-participation membership is open to user organizations, computer E 

735 hardware and software suppliers, government agencies, educational institutions, E 

736 and other interested organizations worldwide. For further information, contact 

737 OSF at Eleven Cambridge Center, Cambridge, MA, Telephone: (617) 621-8700. 

738 Alternatively, contact European headquarters at Open Software 

739 Foundation/Europe, Stefan-George-Ring 29, 8000 Munich 81, Germany, Tele- 

740 phone: (49 89) 930 920, or Open Software Foundation/Japan, ABS Building, 

741 2-4-16 Kudan Minami, Chiyoda-Ku, Tokyo 102, Japan, (81 3) 3 221 9770. 

742 Petrotechnical Open Software Corporation E 

743 Founded in October, 1990, the Petrotechnical Open Software Corporation (POSC) e 

744 was started by BP Exploration, Chevron, Elf Aquitane, Mobil and Texaco to facili- 

745 tate the development of integrated computing technology for the exploration and 

746 production (E & P) segment of the international petroleum industry. Today, 

747 membership is open to all entities interested in the E & P industry. These 

748 members include other petroleum companies, E & P service companies, software 

749 vendors, computer manufacturers, and research institutes. 

750 POSC’s primary mission is the development of an industry-standard, open 

751 systems-based, software integration profile for E & P applications. This platform 

752 will be the interface between petrochemical software applications, database 

753 management systems, workstations and users. POSC activities focus on the 

754 development of an integrated E & P data model, a co mm on look and feel user 

755 front-end, and a set of test suites enabling developers to evaluate their offerings 

756 against selected industry standards. 

757 POSC is moving quickly and has sent out two public requests for inputs in several 

758 technical areas. Project teams for base standards, the E & P data model, and 

759 data access are in place. Staffing is in progress for other projects and special 

760 interest groups have been formed. POSC offerings will be released to industry for 

761 production over the next few years. 
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762 POSC is headquartered in Houston, TX at 10777 Westheimer, Suite 275, Houston, 

763 77042. Telephone: (713) 784-1880. 

764 POSI: Promoting Conference for OSI 

765 The Promoting Conference for OSI was formed in Japan in November 1985 by six 

766 major computer manufacturers and the Nippon Telephone and Telegraph Cor- 

767 poration. Its raison d’etre is to promote the adoption of OSI standards by 

768 cooperating with other international groups that have the same objective, such as 

769 the European-based SPAG and the US-based COS. But conformance testing in 

770 Japan is being developed and will be provided by the INTAP. 

771 For further information, contact (contact information TBD). 

772 SPAG: Standards Promotion and Application Group 

773 The Standards Promotion and Application Group (SPAG), founded in 1983, is a 

774 nonprofit, international research and development consortium of about 65 infor- 

775 mation technology manufacturers and users. In 1986, it became a company 

776 registered under Belgian law as SPAG Services s.a. SPAG’s goals are to promote 

777 multivendor, interoperable products based on international standards, particu- 

778 larly OSI, and to keep its members informed about the latest developments in 

779 functional standards and conformance testing of products. 

780 To achieve its goals, SPAG plays a leading role in the European Workshop on 

781 Open Systems (EWOS), publishes the Guide to the Use of Standards (GUS) regu- 

782 larly, and participates in the development of International Standard Profiles 

783 (ISPs). SPAG is particularly active in the development and marketing of test tools 

784 for manufacturing applications. Through its SPAG-CCT efforts, (a collaboration of 

785 European organizations) which arose out of the ESPRIT Project 955, SPAG is 

786 developing, and will be providing, conformance test tools for testing MAP/TOP 3.0, 

787 and conformance testing services to industry. 

788 SPAG also is working within Europe to implement the certification infrastructure 

789 for OSI products, and is involved in a number of Conformance Test Services (CTS) 

790 projects within the Commission of European Communities (CEC). In addition, 

791 SPAG is active in Telecommunications areas and is leading a consortium develop- 

792 ing verification services for the Broadband Networks project RACE. 

793 Twelve shareholder companies make up SPAG’s board of directors. The original 

794 founding companies—Bull, ICL, Nixdorf, Olivetti, Philips, Siemens, and STET— 

795 occupy seven seats on SPAG’s twelve member board. The shareholder member- 

796 ship was subsequently expanded to include Alcatel, British Telecom, Digital 

797 Equipment Corp., Hewlett-Packard, and IBM, who occupy the five remaining 

798 board seats. 

799 SPAG has close working relationships with its counterparts in North America 

800 (COS) and the Far East (POSI). 

801 For further information, contact Graham Knight, at SPAG Services s.a., Stan- 

802 dards Promotion and Application Group (SPAG), Avenue des Arts, 1-2 bte 11, 1040 

803 Brussels, Belgium, Telephone: 32 2 210 08 11, Fax 32 2 210 08 00. 
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804 SQL Access Group 

805 The SQL Access Group is a vendor group formed by a number of people in the ISO 

806 Remote Data Access (RDA) Group. 

807 The SQL Access Group’s charter is several fold. First, the Group is chartered to 

808 define a co mm on subset of SQL functions to reconcile the many SQLs that exist. E 

809 The specifications will include an SQL data format, as well as protocols for moving 

8 10 data within a multivendor SQL environment. Also included will be specifications 

8 11 for an enhanced SQL programming interface that will let developers write a single 

812 application that can access a variety of SQL databases. These SQL Access 

813 specifications are scheduled to be published in late 1991. 

814 The SQL Access Group’s second charter is to accelerate the work of the RDA group. 

815 Third, the SQL Access Group is working on putting more distributed functionality 

816 into RDA. Toward this end, each thing accomplished by the SQL Access group is 

817 fed back into the RDA group. 

818 For further information, contact the SQL Access Group at (Address TBD). 


819 UniForum E 

820 UniForum is a nonprofit international association of open systems professionals. E 

821 Founded in 1980 as /usr/group, the association has, through its standards com- E 

822 mittees and technical committees, provided contributions to various standards E 

823 and continues to be involved in the formal standards development process. The E 

824 specifications and standards to which UniForum has contributed include: E 

825 — The 1984 /usr/group Standard was contributed as a base document for the e 

826 IEEE P1003.1 work. E 

827 — The UniForum Technical Committee on Real Time meets jointly with the E 

828 IEEE P1003.4 working group, working on the emerging POSIX realtime E 

829 standards. e 

830 — The UniForum Technical Committee on Supercomputing evolved into the E 

831 IEEE P1003.10 working group. E 

832 — The UniForum Technical Committee on Transaction Processing evolved e 

833 into the IEEE P1003.11 working group. E 


834 — The UniForum Technical Committee on Internationalization has contri- E 

835 buted specifications to the IEEE P1003.1 and P1003.2 working groups and E 

836 the ANSI X3J11 standard C committee and continues to be a technical E 

837 resource for both formal and informal standards development bodies. e 

838 UNIX International/UNIX System Laboratories E 

839 UNIX International (UI) is a nonprofit industry organization formed to represent E 

840 hardware manufacturers, system integrators, independent software vendors, 

841 value-added resellers, end-users, government agencies worldwide, industry stan- 

842 dards bodies, and academic and research institutions who want to direct the evo- 

843 lution of System V UNIX and its corresponding specification, the System V E 
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844 Interface Definition (SVID). It has since expanded its scope to provide a frame- E 

845 work for UNIX-based open systems work in the areas of desktop computing, cor- 

846 porate hub computing, distributed computing, and an enterprise-wide framework E 

847 known as “Atlas.” e 

848 Unlike X/Open, OSF, AT&T, and the IEEE, UI does not produce specifications, 

849 software, or standards. Its functions range from specifying technical and timing 

850 requirements for future System V versions and making suggestions about specific 

851 function designs to influencing AT&T UNIX licensing policies. 

852 Using its “one-member, one-vote” approach, UI members formulate a consensus 

853 regarding the requirements and technical specifications for new System V UNIX 

854 versions. UI delivers its requirements to UNIX System Laboratories (USL), the 

855 AT&T spinoff that develops, distributed, and licenses UNIX. UI is USL’s primary 

856 input source on technical requirements, conformance, and timing of releases. USL 

857 is committed to implement software to satisfy UI’s requirements, unless there is a 

858 reason not to. 

859 E 

860 For further information, contact UNIX International, Waterview Boulevard, Par- 

861 sippany, NJ 07054, (201) 263-8400 or (800) 848-6495. In Europe, contact UNIX 

862 International, Avenue de Beautieu 25, 1160 Brussels, Belgium, (32-2-672-3700). 

863 In the Asian Pacific region, contact Karufuru-Kanda Bldg. 8F, 1-2-1 Kanda 

864 Suda-cho, Chiyoda-du Tokyo 101, Japan, (81) 3-5256-6959. 

865 User Alliance for Open Systems 

866 The User Alliance for Open Systems was formed from two informal organizations 

867 (the Atlanta 17 and the Houston 30). The Alliance is currently a Requirements 

868 Interest Group (RIG) of the Corporation for Open Systems International (COS). 

869 The Alliance is dedicated to overcoming barriers to open systems and speeding 

870 the development and deployment of open systems products. It intends to act as a 

871 catalyst toward the development and use of open systems. It will develop no 

872 specifications or products. Rather, the Alliance will create and support processes 

873 to influence and accelerate the availability of open systems technology (e.g., a 

874 repository of information about the cost benefits of open systems). 

875 In 1990 the organization began its work by identifying barriers to open systems 

876 and global actions to eliminate those barriers. In 1991 the organization intends 

877 to start bringing resources to bear to achieve its goals. The Alliance has had one 

878 formal meeting (Dallas, March 1991) and will have its second formal meeting in 

879 McLean, Virginia in Nov. 1992. Alliance committee work is ongoing throughout 

880 this period with three major subgroups in the formative stages. 

881 For further information, contact the Corporation for Open Systems, 1750 Old 

882 Meadow Road, Suite 400, McLean, VA 22102-4306, Telephone: (703) 883-2700. 
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883 X.400 API Association 

884 The X.400 API (Application Programming Interface) Association is an industry 

885 association formed initially to bring X.400 messaging into the PC LAN world. 

886 There are more than twenty companies in the association, and they include most 

887 of the current X.400 players. 

888 Among its activities, the X.400 API Association developed an X.400 Application 

889 Programming Interface specification in conjunction with X/Open. These inter- 

890 faces, completed in September 1990, are jointly owned by the X.400 API Associa- 

891 tion and X/Open. The two organizations contributed these interface specifications 

892 to the P1224 Group to use as a basis for the P1224 standard. 

893 For further information contact (Address and other contact information: TBD) 

894 X/Open 

895 X/Open is an independent, nonprofit consortium formed in 1984. Its goals are to E 

896 determine user and market requirements and to specify a complete, source-level- E 

897 portable application environment and test suites. Although its members were ini- E 

898 tially vendors, X/Open’s membership now encompasses users, system integrators, 

899 value-added resellers, government agencies worldwide, other industry-standards 

900 groups, and academic and research institutions. 

901 E 

902 The X/Open environment includes specifications for an operating system inter- 

903 face, networking, data management, programming languages, floppy disk for- 

904 mats, internationalization, and distributed transaction processing. The X/Open 

905 Group does not normally define standards for these areas. Instead, it chooses 

906 from existing and emerging standards. An X/Open market research program and E 

907 open user requirements congress identify and prioritize user and market require- E 

908 ments, based on input solicited from users. These prioritized requirements are E 

909 published in a document known as the Open Systems Directive . These prioritized E 

910 requirements also help drive the X/Open specification process. The X/Open E 

911 specifications are published in a series of books known as the X/Open Portability e 

912 Guide. e 

913 The X/Open environment is based on the ISO/IEC 9945-1 core POSIX (POSIX.1 {2}) E 

914 standard, parts of AT&T’s System V Interface Definition (SVID), and formal inter- E 

915 national standards that are already accepted or likely to be accepted. However, to 

916 rapidly get standards into the field for practical use, where no formal standards 

917 exist, X/Open specifies industry standards and widely-accepted de facto standards 

918 (including some based on real-world products that have achieved consensus in the 

919 marketplace). In some instances where neither formal nor de facto specifications 

920 exist but there is a strong need for standards (e.g., internationalization and tran- 

921 saction processing), X/Open has itself defined specifications. 

922 E 

923 For further information, contact X/Open Company Ltd. at Apex Plaza, Forbury 

924 Road, Reading, Berkshire, RG1 1AX, UK, Telephone: 44 734 508 311. In the US, 

925 contact X/Open at 1010 El Camino Real, Menlo Park, CA 94025, Telephone: 
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(informative) 
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1 Responsibility: Kevin Lewis 

2 The following table lists currently-known e-mail addresses for active working 

3 group members. To correct your entry, send e-mail directly to Hal Jespersen, 

4 listed below. 


5 

6 

7 

8 

9 

10 
11 
12 

13 

14 

15 

16 

17 

18 

19 

20 
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23 

24 

25 

26 

27 

28 

29 

30 

31 
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rich@tecr.nosc.mil 
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conrad_bud@tandem.com 
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(informative) 

Additional Material 


1 E.l Software Development Environments 

2 Responsibility: Don Folland 

3 E.1.1 Overview and Rationale 

4 Software Development Environments are dealt with as a particular application 

5 area needing special attention for the following reasons: 

6 — The domain of Software Development Environments is one of prime impor- 

7 tance. Software development is a major area of expenditure for govern- 

8 ment and large commercial organizations. 

9 — The need for standardization is being driven not only by the SDE vendors 

10 and users, but also by the Independent tool developers who want to get 

n their tool products on as many vendor platforms as possible. 

12 — The SDE domain calls not only for portability, but also for particular 

13 integration and interoperability requirements. 

14 — The domain is primarily of interest to that user community that has large 

is complex software development requirements, but it is also of interest to all 

16 application areas as software development is an enabling technology for all 

17 applications. 

18 Software engineers seek more powerful assistance to improve productivity and 

19 quality in the software development process. Considered opinion currently favors 

20 Project Support Environments (PSE) underpinned in such a way that the facilities 

21 are capable of being implemented on different machines. A PSE needs a base 

22 holding information such as specifications, designs, code, schedules, configuration 

23 plans, tests, etc., to support the developers. The interface between the base and 

24 the tools must ensure portability of the tools. Again, these tools will be supported 

25 by relevant language standards. 

26 Certain design methodologies themselves have been modeled formally to establish 

27 their degree of rigor and self-consistency. Function Point Analysis is one method 

28 of measuring software systems and computing productivity that is increasing in 

29 use. It measures inputs, outputs, and entities accessed to determine transaction 
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30 size; it gauges technical complexity by reference to 19 characteristics. These are 

31 combined to give a measure of systems size. Productivity is the ratio of system 

32 size in function points to the effort required to produce or maintain the system. 

33 Generally, software support for the development process is in its infancy and 

34 effective metrics have not yet been developed. 


35 E.1.2 Scope 


36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 

47 

48 

49 

50 

51 

52 

53 

54 

55 

56 

57 

58 


The problem domain is complex software development, from the generation of an 
idea to the delivery and ongoing support of a solution product set. 

Thus, an SDE may include some or all of the following: 

(1) Software Development Life Cycle 

(a) Requirements analysis 

(b) Logical design 

(c) Physical design 

(d) Functional and interface specification 

(2) Activity support 

(a) Prototyping 

(b) Program development and testing 

(c) Quality assurance and regression testing 

(d) Generation of user documentation 

(e) User training 

(f) Problem report tracking and maintenance 

(g) Maintenance and tracking of schedules 

(3) Configuration Management 

(a) Automatic version management 

(b) Integrity management 

(c) Traceability 

(4) Project Management 

(5) Data Administration 
(a) Access control 


59 In the context of developing software for a POSIX Open System Environment, 

60 design will take account of portability and interoperability requirements. The 

61 SDE tools themselves should be portable. The software development activities 

62 may be provided with a large set of tools and applications. The SDE must provide 

63 the necessary support for the integration of all of these tools. 
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64 E.1.3 Reference Model 

65 _ 



Tool API 


Database API 


66 _ 

67 Figure E-l - Software Development Model 

68 In this clause the conceptual view of software development is related to the POSIX 

69 Reference Model (Figure 3-1). The software developer’s view is shown in 

70 Figure E-l. The tools used to develop software can be viewed as applications in 

71 their own right in the context of the POSIX Reference Model, requiring the same 

72 services from the platform as for Database Management. 

73 In the Software Development Model, the Environment Adaptation and Project 

74 Support Tools “layer” provides the essential link between the programmer, 

75 designer or analyst, the design method, and the development infrastructure. At 

76 this level are provided the tools and applications that are unique to the project or 

77 methodology; e.g., project management workbench. It requires support from a 

78 consistent human-computer interface to the Functional Tools. 

79 The Functional Tools and Integration Mechanisms embrace the essential tool set 

80 to enable software developers to build software. It includes simple tools such as 

81 editors, tools for tool-building, and integration mechanisms. There will be tools 

82 for Configuration Management, Version Management, and System Administra- 

83 tion. It is not within the scope of this guide to discuss these in detail. 

84 The whole software development environment is underpinned by essential 

85 management systems, such as object management system, a data dictionary, a 

86 user interface management system, and environment management. A database 

87 will frequently be established to hold specifications, designs, configuration plans, 

88 etc. 
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89 


Software Development Services API: 

— Data Definition and Manipulation Services 

— Data Access and Integrity Services 

— Object Management Services 

— Miscellaneous Services 


Software Development 
Services EEI 


90 _ 

91 Figure E-2 - Software Development Reference Model 

92 In the POSIX Open System Environment, the software development model can be 

93 incorporated into the POSIX Reference Model as in Figure E-2. The model shows 

94 that the tools and services required by the software developer are part of the 

95 POSIX Open System Environment and are available through the POSIX OSE API. 

96 E.1.4 Services Requirements 

97 Software developers, i.e., designers, analysts, and programmers, use software 

98 applications to facilitate the complex task of software development. A tool will 

99 require services from the application platform and will frequently require support 

100 from another application in the application set. There are many possible imple- 

101 mentations of tool sets. Descriptions of these are beyond the scope of this guide. 

102 E. 1.4.1 Application Program Interface Services 

103 The services required at the API are essentially similar to those described for 

104 Database Management in 4.4.4.1; i.e., Data Definition and Manipulation, Data 

105 Access, Data Integrity, and such Miscellaneous Services as Data Dictionary. 

106 E.1.4.2 External Environment Interface Services 

107 A consistent human-computer interface to the tool set is required. Some of the 

108 programmer’s tool set will be explicitly focused on windowing services (such as 4.7 

109 and 4.8) and provide assistance to develop software with improved usability. 

no Resource data formats must be specified in order to ensure effective information 

in interchange [for example, CASE Data Interchange Format (CDIF)], for which stan- 

112 dards are currently under development under the aegis of the CDIF Technical 
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113 Committee (see also E.1.5.2 and 4.5). 

H4 Protocol services are required for the transport of data (see 4.3). 

115 E.1.4.3 Interapplication Software Entity Services 

116 Many of the tools depend for interface between one another upon the data 

117 dictionary/repository, which is a key software component and which may concep- 

H8 tually be regarded as part of the Applications Platform. Included in this category 

119 will be utilities for servicing the DBMS, such as recovery, reorganization, and res- 

120 tructure: 

121 — Object management system 

122 — User interface management system 

123 — Database management system 

124 — Transaction processing management system 

125 Details of these management systems may be recorded in the data 

126 dictionary/repository. 

127 E.1.4.4 Software Development Resource Management Services 

128 These services are generally not visible to the programmer or software developer 

129 at the Tools API, usually being provided by the tool building and other software 

130 development utilities. 

131 E.1.5 Standards, Specifications, and Gaps 

132 This subclause describes current accepted standards that are relevant to this area 

133 in addition to the language standards in 4.1.5 and the database standards in 

134 4.4.5. 

135 E.1.5.1 Current Standards 

136 This subclause briefly identifies the current standards in this area. 

137 The following provides place holders for further text to be inserted - assistance 

138 required please. 

139 E.1.5.1.1 International Standards 

140 Labeling and File Structure of Magnetic Media 

141 The following standards refer to the labeling of magnetic media and for the file 

142 structure on such media to facilitate information interchange: 

143 Labeling of magnetic tape ISO 1001 

144 Labeling of cassette and cartridge ISO 4341 
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145 Table E-l - Software Development Standards 

146 _ 


147 

Service 

Specification 

Subclause 

148 

Miscellaneous Services: 



149 

Labeling of magnetic tape 

ISO 1001 

4.11.5.? 

150 

Labeling of cassette and cartridge 

ISO 4341 

4.11.5.? 

151 

Labeling of flexible disks 

ISO 7665 

4.11.5.? 

152 

Volume and file structure for flexible disks 

ISO 9293 

4.11.5.? 

153 

Volume and file structure for CD-ROM 

ISO 9660 

4.11.5.? 

154 

Documentation symbols and flowchart conventions 

ISO 5807 

4.11.5.? 

155 

Documentation of applications 

ISO 6592 

4.11.5.? 

156 

Program flow for sequential files 

ISO 6593 

4.11.5.? 

157 

Data descriptive file for information interchange 

ISO 8211 

4.11.5.? 

158 

Program constructs and conventions 

ISO 8631 

4.11.5.? 

159 

User documentation 

ISO 9127 

4.11.5.? 

160 





161 Labeling of flexible disks ISO 7665 

162 Volume and file structure for flexible disks ISO 9293 

163 Volume and file structure for CD-ROM ISO 9660 

164 Data descriptive file for information interchange ISO 8211 

165 The above-mentioned standards might be more suitably called out in Richard 

166 Scott’s section 4.5. 

167 Software Documentation 

168 There are several standards dealing with documentation to assist with the task of 

169 software development, and therefore potentially facilitating programmer and 

170 designer portability, as well as user documentation. 

171 

172 

173 

174 

175 

176 

177 

178 

179 

180 
181 
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182 E. 1.5.1.2 Regional Standards 

183 ECMA has approved ECMA-149 as the standard for the Portable Common Tool 

184 Environment (PCTE). 

185 E. 1.5.1.3 National Standards 

186 To Be Provided 

187 E.1.5.2 Emerging Standards 

188 This subclause describes the activities currently in progress to further standard- 

189 ize this area. 

190 E.l.5.2.1 International Standards 

191 To Be Provided 

192 E.l.5.2.2 Regional Standards 

193 To Be Provided 

194 CASE Data Interchange Format (CDIF) 

195 The CDIF Technical Committee is developing a data interchange format to serve 

196 as an industry standard for exchanging information between Computer-Aided 

197 Software Engineering (CASE) tools. CDIF is an EIA-endorsed initiative. It 

198 assumes that two or more tools may interface asynchronously with each other and 

199 will transfer information from one to another via “CDIF files.” The types of infor- 

200 mation that may be contained in these files is defined by the CDIF Conceptual 

201 Models. 

202 Portable Common Tool Environment (PCTE) 

203 ECMA TC33 has responsibility for the development and maintenance of PCTE. 

204 The committee formed a Task Group in 1988 to develop a Reference Model which 

205 would assist the standardization process. Such a model has been developed 

206 totally independent of PCTE, and is described in ECMA Technical Report 55. The 

207 model provides a way to describe, compare, and contrast CASE environment 

208 frameworks. 

209 E.l.5.2.3 National Standards 

210 To Be Provided 

2 11 E.l.5.2.4 National Standards 

212 To Be Provided 
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213 E.1.5.3 Gaps in Available Standards 

214 E.l.5.3.1 Public Specifications 

215 To Be Provided 

216 E.l.5.3.2 Unsatisfied Service Requirements 

217 To Be Provided 

218 E.1.6 OSE Cross-Category Services 

219 Not applicable. 

220 E.1.7 Related Standards 

221 To Be Provided 

222 E.1.8 Open Issues 

223 — Relationship between methodology and formats 

224 [PCTE and CAIS-A have been moved here largely because it is not clear what to do 

225 with them. They are not adequately accommodated by this model. They are both 

226 hybrids of operating system and database management system capabilities that 

227 seem to belong either everywhere or nowhere. They could both well be used in con- 

228 junction with a P1003.1 implementation, but they could also be implemented on 

229 other base operating systems, or implementations could even expand their capabili- 

230 ties to provide full operating systems. P1003.0 must decide what to do with them.] 

231 PCTE 

232 An effort by the European Computer Manufacturers Association (ECMA) has 

233 resulted in the definition by Technical Committee 33 of the Basis for the Portable 

234 Common Tools Environment (PCTE). This is now an ECMA standard and is 

235 referred to as Standard ECMA-149. 

236 CAIS-A 

237 MIL-STD-1838A (CAIS-A) was developed by the US Department of Defense to pro- 

238 vide a common foundation for Ada Programming Support Environments. Similar 

239 in nature to PCTE (see above), it too covers many of the system services covered by 

240 4.2.4. In addition, it provides data management services such as those discussed 

241 in 4.4 and data interchange services (specifically, a Co mm on External Form) simi- 

242 lar to those discussed in 4.5. 
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